I am trying to debug u-boot on a PowerPC (MPC8260) target
configured to have u-boot located from address 0x0
after reset.
Basically, u-boot have to be linked to some other address since
RAM must be allocated to address 0x0, so I need to use the
'add-symbol-file' command until the memory mapping is
changed by u-boot.
The problem is that 'add-symbol-file' seems to work as expected
for anything but address 0x0, where it actually seems to add
an offset 0x80000000. I have tested quite a bit, and it only
seems to be a problem for address 0x0.
The following illustrates my case:
(gdb) show version
GNU gdb 6.8
This GDB was configured as "--host=i686-pc-linux-gnu
--target=powerpc-linux".
(gdb) print &_start
$1 = (<text variable, no debug info> *) 0x40000100 <_start>
symb
(gdb) add-symbol-file u-boot 0x0
add symbol table from file "u-boot" at .text_addr = 0x0
(gdb) print &_start
$2 = (<text variable, no debug info> *) 0x80000100 <_start>
(gdb) symb
(gdb) add-symbol-file u-boot 0x4
add symbol table from file u-boot" at
.text_addr = 0x4
(gdb) print &_start
$3 = (<text variable, no debug info> *) 0x104 <_start>
I actually finished my singlestepping using the address offset 0x4,
and then just noticing that the debugger showed the line one
instruction ahead (PowerPC instruction are 4 bytes long). But
this really seems to be a bug (sign issue?), and I thought it
might be worth some follow-up.
I googled a bit, but the only related I could find was actually
from the u-boot forum back in 2003, indicating that it was a bug
in GDB:
http://lists.denx.de/pipermail/u-boot/2003-August/002087.html
Anyone would happen to know anything about this, and current status?
I realize my GDB version is not the latest, but if the problem
dates back to 2003 at least, then it might still be there.
Any comment is appreciated.
Sincerely
Kristian
_______________________________________________
bug-gdb mailing list
bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb
