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

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

[Vladimir Gurevich]

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

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

[Wolfgang Denk]

In message <3E41B76C.8060207@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

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

[Vladimir Gurevich]

Hello Wolfgang,

Wolfgang Denk wrote:
> 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.

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