Re: [Openocd-development] How to debug a program not run at it'sruntime address

[Michael S. <rin...@di...>]

dswei wrote:
>         I can load the kernel throught TFTP to the memory, and the in the GDB, use the command 'file vmlinux' to load the 
> symbols.  But these symbols is for virtual address.
>         The first section of kernel, is to create the page table, and then enable MMU. If I want to debug this section, I can
> only use the 'telnet localhost 4444' to enter some OpenOCD's commands. But I can't use the IDE such as Eclipse, because
> the gdb can't apply the symbols before the MMU is enabled.

I don't know about eclipse, but with ddd, you can open the machine code (assembly) view and single-step from there.

The only better alternative would be to create a symbol table that contains the symbols in the not-yet-relocated (MMU off) form - however, that depends on the load address you use, and thus requires some twiddling for each usage. It might be able to hack something that applies a user-defined offset to a list of symbols using libbfd, objcopy, dwarf tools etc.

I do not know a tool that does this, however. When debugging bootloader code, where the code copies itself to some RAM location, I have found two working strategies:

 - make the relocation code straightforward and small, so that it can be easily debugged using only the machine code view and without symbols displayed. The ARM Linux startup is not very nice in this regard - assembly code that uses include and macros makes it difficult to compare the running assembly view to the source code.

 - link the code in two separate chunks. Link the relocation code as a separate ELF file, with correct symbols etc., and append the relocated image, which is linked as a second ELF file. How the first image finds the entry to the second and how the two images are combined into one downloadable file depends on your needs.

Nevertheless, I guess debugging startup code will never be simply point-and-click - it is quite lowlevel stuff, and requires some assembly knowledge. And in most cases, you won't do this for long - when the startup works, you can switch to more comfortable debugging methods.

cu
Michael