uboot调试和符号

用gdb第一阶段调试的时候，符号应该没有任何问题。

但是由于uboot将自己拷贝到RAM里面去。随后跳转到RAM执行。所以debug的时候符号就失效了。

比如初始的地址是abc。拷贝后的地址是1000abc。随后跳转到0x1000xxx的地址执行了,而你的break do_mem_md，依然在原来的abc。这样就无法中断下来。

为了解决这个问题。要重新加载符号表。

总的uboot相关资料参考

http://www.denx.de/wiki/DULG

用户手册参考

http://www.denx.de/wiki/DULG/Manual

其中第10章就解决了符号表调试的问题。

FAQ参考

http://www.denx.de/wiki/DULG/Faq

用户手册第十章 调试uboot就解决了这个问题。

http://www.denx.de/wiki/view/DULG/DebuggingUBoot

重定位之后的调试在第10.1.2

For debugging U-Boot after relocation we need to know the address to which U-Boot relocates itself to. When no exotic features like PRAM are used, this address usually is <MAXMEM> -CONFIG_SYS_MONITOR_LEN. In our example with 16MB RAM and CONFIG_SYS_MONITOR_LEN = 192KB this yields the address 0x1000000 - 0x30000 = 0xFD0000.

In other cases, check the source code, and apply some common sense. For example, on Power Architecture® we use "r2" to hold a pointer to the "global data" structure ("struct global_data"); this structure contains a field

unsigned long   relocaddr;      /* Start address of U-Boot in RAM */

which is the start addresses of U-Boot after relocation to RAM. You can easily print this value in gdb like that:

(gdb) print/x ((gd_t *)$r2)->relocaddr

With this knowledge, we can instruct gdb to forget the old symbol table and reload the symbols with our calculated offset:

(gdb) symbol-file
Discard symbol table from `/home/dzu/denx/cvs-trees/u-boot/u-boot'? (y or n) y
No symbol file now.
(gdb) add-symbol-file u-boot 0xfd0000
add symbol table from file "u-boot" at
        .text_addr = 0xfd0000
(y or n) y
Reading symbols from u-boot...done.
(gdb) b board_init_r
Breakpoint 2 at 0xfd99ac: file board.c, line 533.
(gdb) c
Continuing.

Breakpoint 2, board_init_r (id=0xfbb1f0, dest_addr=16495088) at board.c:533
533     {
(gdb)

board_init_r  is the first C routine running in the newly relocated C friendly RAM environment.

The simple example above relocates the symbols of only one section, .text. Other sections of the executable image (like .data, .bss, etc.) are not relocated and this prevents gdbfrom accessing static and global variables by name. See more sophisticated examples in section 10.3. GDB Startup File and Utility Scripts.

我是自己尝试的 直接在源码中寻找u-boot的重定位位置 0x1bf6a000 。

然后使用

symbol-file 移除原来的符号

在使用

add-symbol-file u-boot  0x1bf6a000

来加载符号，这样所有的调试都可以进行了。