GDB没有正确地拆解在RAM中运行的程序

时间:2014-08-18 03:15:23

标签: debugging gcc arm ram disassembly

我有一个使用GCC编译的应用程序用于STM32F407 ARM处理器。链接器将其存储在Flash中,但在RAM中执行。一个小的引导程序将应用程序从Flash复制到RAM,然后分支到应用程序的ResetHandler。

memcpy(appRamStart, appFlashStart, appRamSize);

// run the application
__asm volatile (
    "ldr  r1, =_app_ram_start\n\t"    // load a pointer to the application's vectors
    "add  r1, #4\n\t"                 // increment vector pointer to the second entry (ResetHandler pointer)
    "ldr  r2, [r1, #0x0]\n\t"         // load the ResetHandler address via the vector pointer
                                      // bit[0] must be 1 for THUMB instructions otherwise a bus error will occur.
    "bx   r2"                         // jump to the ResetHandler - does not return from here
);

这一切都正常,除非我尝试从RAM调试应用程序(使用Eclipse中的GDB),反汇编是不正确的。奇怪的是调试器获取源代码是正确的,并将接受并停止我设置的断点。我可以单步执行源代码行。但是,当我单步执行装配说明时,它们完全没有任何意义。它还包含许多未定义的指令。我假设它是某种对齐问题,但这对我来说都是正确的。有什么建议吗?

1 个答案:

答案 0 :(得分:0)

GDB可能依赖于符号表来检查可以是Thumb(2)/ ARM的指令集模式。当您将代码移动到RAM时,它可能无法找到此信息并选择返回ARM模式。

您可以在gdb中使用set arm force-mode thumb强制使用Thumb模式指令。

作为旁注,如果在调试ARM二进制文件时遇到非法指令,如果不像试图反汇编数据部分那样完全无意义,这通常是个问题。

我个人觉得奇怪的是,在拆卸ARM二进制文件时,工具不会尝试启发式方法。在 auto 的情况下,不应该尝试这两种模式并进行错误计数以决定使用哪种模式作为最后的手段。