[U-Boot-Users] Debugging U-boot after relocation

Wolfgang Denk wd at denx.de
Thu Feb 6 08:10:37 CET 2003

In message <3E41B76C.8060207 at paulidav.org> you wrote:
> I can debug U-boot before the relocation step easily. So I
> put a breakpoint at the "blr" instruction that preceeds the
> "in_ram" label. After it occurs, I issue the following gdb
> commands:
> (gdb) info line *(&in_ram)
> Line 1310 of "/home/vgurevic/vag/u-boot-0.2.0/cpu/ppc4xx/start.S"
> starts at address 0xfffc25a8 <in_ram> and ends at 0xfffc25ac <in_ram+4>.
> (gdb) file
> (gdb) add-symbol-file u-boot 0x7fd0000  <- That's the reloc. addr
> (gdb) target remote bdi:2001
> (gdb) info line *(&in_ram)
> Line 510 of "/home/vgurevic/vag/u-boot-0.2.0/cpu/ppc4xx/start.S"
> starts at address 0x7fd26e8 <ext_bus_cntlr_init> and ends at 0xfffc0100.
>                                                              ^^^^^^^^^^^
> So that's where the isue is: gdb can't interpret line numbers
> correctly anymore and can't show (via ddd or emacs interface)
> where you are. It is still possible to step through the code
> using "stepi" but not much more.

Did you  use  "symbol-file"  without  argument  to  delete  the  old,
flash-based  symbol  table  first?  Otherwise  GDB  may  get confused
because there are two sym,bol tables loaded which  contain  the  same
symbols at different addresses.

> Does anyone know how to deal with this issue or maybe there is
> a totally different way to debug U-boot?

Except for the missing (?) "symbol-file" command everything looks  OK
to me. And it works here (although I never used "info line" yet).

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
If it's working, the diagnostics say it's fine. If it's not  working,
the diagnostics  say  it's  fine.
              - A proposed addition to rules for realtime programming

More information about the U-Boot mailing list