c - 断点在带有 QEMU 模拟 cortex-a8 的 gdb 中不起作用

Question

我正在测试在 ARM7TDMI 中运行的一些简单代码，因为我在 QEMU 上没有找到 ARM7TDMI 模拟器，所以我使用 Cortex-a8 代替(我不确定这是否会导致错误，完全新手)。
这就是我运行 QEMU 的方式:
qemu-system-arm -machine realview-pb-a8 -cpu cortex-a8 -nographic -monitor null -serial null -semihosting -kernel main.elf -gdb tcp::51234 -S

我要测试的代码很简单，函数LoadContext()和SaveContext()是用IAR IDE的arm汇编编写的，IAR IDE使用ARM7TDMI作为核心。我使用 IAR 将此汇编文件编译为目标文件，并将下面的代码链接到 arm-none-eabi-gcc ，这会导致不可预测的错误吗？ (只想使用 gcc 和 QEMU 而不是 IAR...)

int main(void)
{

    Running = &taskA;
    Running->PC = task1;
    Running->SP = &(Running->StackSeg[STACK_SIZE-1]);

    LoadContext();
}

void task1(void)
{
    register int reg_var = 1;
    volatile int vol_var = 1;

    SaveContext();
    reg_var++;
    vol_var++;

    SaveContext();
    reg_var++;
    vol_var++;

    LoadContext();
}

所以，当我在 gdb 中设置断点时，它不起作用，我认为它会进入无限循环。我查了一下初始化过程，是:

(gdb) 
0x000082f6 in __libc_init_array ()
(gdb) 
0x000080e2 in _start ()
(gdb) 
0x000080e4 in _start ()
(gdb) 
0x000080e6 in _start ()
(gdb) 
main () at src/context-demo.c:12
12  int main(void) {
(gdb) 
0x000081ea  12  int main(void) {
(gdb) 
0x00000008 in ?? ()
(gdb) 
0x0000000c in ?? ()
(gdb) 
0x00000010 in ?? ()
(gdb) 
0x00000014 in ?? ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00000004 in ?? ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00000004 in ?? ()
(gdb) 

有人对这里发生的事情有任何想法吗？感谢任何帮助，谢谢!

Answer 1

如果你告诉 gdb 告诉你它正在执行的汇编指令(“display/3i $pc”将在每次 gdb 停止时打印接下来的 3 条指令)，并执行单步操作，你会发现调试起来容易得多单个指令(“stepi”)。

某些原因导致您意外地到达低地址 0x8，您需要找出那是什么。要么你真的跳转到 0x8，要么你已经发生了异常。查看每台机器指令级别的执行情况会告诉您它是什么。

这里有一些可能的可能性:

• 构建可执行文件，假设它有 RAM，而 realview-pb-a8 没有 RAM - 这通常表现为“默默地写入堆栈(或全局变量)不执行任何操作，从堆栈/全局读取返回 0” ，所以如果你在全局中有一个函数指针，或者你尝试将返回地址压入堆栈然后弹出它，你最终会得到 0
• 构建可执行文件，假设它在提供 SVC API 的操作系统下运行 - 在这种情况下，代码将执行 SVC 指令，并且您的代码将崩溃，因为 SVC 异常 vector 中没有任何内容可以处理它
• 为错误的 CPU 类型构建的可执行文件并执行 UNDEF 的指令(这应该会导致执行到地址 0x4，即 undef vector ，但我感觉它的 gdbstub 中存在 qemu bug，这可能意味着该步骤执行 UNDEF insn 直到执行 UNDEF vector 处的第一个 insn 后才会停止)
• 构建为假定 FPU 始终启用的可执行文件。当 QEMU 执行这样的“裸机”二进制文件时，CPU 在硬件启动的状态下启动，其中 FPU 被禁用。因此，除非可执行文件的启动代码已显式打开 FPU，否则任何使用 FPU 的指令都将 UNDEF。

我已经按照您的情况的大概概率顺序列出了这些内容，但无论如何，通过机器指令单步执行应该可以确定发生了什么。