[SOLVED] GDB doesn't disassemble program running in RAM correctly

Issue

I have an application compiled using GCC for an STM32F407 ARM processor. The linker stores it in Flash, but is executed in RAM. A small bootstrap program copies the application from Flash to RAM and then branches to the application's 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
);

This all works ok, except when I try to debug the application from RAM (using GDB from Eclipse) the disassembly is incorrect. The curious thing is the debugger gets the source code correct, and will accept and halt on breakpoints that I have set. I can single step the source code lines. However, when I single step the assembly instructions, they make no sense at all. It also contains numerous undefined instructions. I'm assuming it is some kind of alignment problem, but it all looks correct to me. Any suggestions?

Solution

It is possible that GDB relies on symbol table to check instruction set mode which can be Thumb(2)/ARM. When you move code to RAM it probably can't find this information and opts back to ARM mode.

You can use set arm force-mode thumb in gdb to force Thumb mode instruction.

As a side note, if you get illegal instruction when you debugging an ARM binary this is generally the problem if it is not complete nonsense like trying to disassembly data parts.

I personally find it strange that tools doesn't try a heuristic approach when disassembling ARM binaries. In case of auto it shouldn't be hard to try both modes and do an error count to decide which mode to use as a last resort.

Answered By - auselen