Debugging U-boot after relocation

Hello,

I am trying to debug U-boot after the code has been relocated and I got some problems. Maybe I don't know gdb well enough... BTW, I use ELDK tools and BDI-2000 on PPC405GP-based board.

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@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.

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

Thanks,
Vladimir

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.

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

Hello Wolfgang,

Actually, the empty "file" command that I used is supposed to have the same effect. Anyway, I tried your suggestion, and problems are still there.

A good example might be:

(gdb) symbol-file
No symbol file now.
(gdb) add-symbol-file u-boot 0x7fd0000
add symbol table from file "u-boot" at

        .text_addr = 0x7fd0000

(y or n) y
Reading symbols from u-boot...done.
(gdb) break start.S:1338
Breakpoint 1 at 0xfffc2600: file /home/vgurevic/vag/u-boot-0.2.0/cpu/ppc4xx/start.S, line 1338.

                ^^^^^^^^^^
(gdb) list 1338
1333            add     r0,r0,r11
1334            stw     r10,0(r3)
1335            stw     r0,0(r4)
1336            bdnz    3b

1337 4:
1338 clear_bss:
1339 /*
1340 * Now clear BSS segment
1341 */
1342 lwz r3,GOT(.bss)
(gdb) p &clear_bss
$1 = (<text variable, no debug info> *) 0x7fd2600 <clear_bss>

As you can see, gdb relocated the address for the symbol in .text session (clear_bss), but failed to relocate addresses associated with line numbers.

This completely screwes up ddd and Emacs gdb interfaces, since they (often) don't know which line to show. This also screwes up next, step and "execute-till-here" (implemented via tbreak at a line number).

Can it be a gdb "feature" or there is a way to tell it about line numbers?

Could you tell me in more details how do you debug U-boot then?

Thanks,
Vladimir