debugging U-boot with GDB on a Au1550

I have U-boot running on a Au1550 platform. I have verified that re-location to RAM works but the system is crashing somewhere in board_init_r. I would like to debug this with GDB and a BDI2000, but am running into a few issues. U-boot for this platform is linked to 0xbfc00000 (the ROM reset vector). This is not what I am used to as most ARM platforms are linked to the RAM location. After U-boot is relocated to RAM, how do I tell GDB what the new link address is (0x80fdc000 in this case)?

Thanks,
Cliff

=======================
Cliff Brake
http://bec-systems.com

May I suggest that you start reading the manual? Especially section
http://www.denx.de/twiki/bin/view/DULG/DebuggingUBoot#Section_10.1.2.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Time is an illusion perpetrated by the manufacturers of space.

Thanks for the suggestion -- very helpful. Things still are not working for me. Setup:

- Au1550
- U-boot CVS tip
- using MIPS toolchain from ELDK 3.3.1
- BDI2000

When I try to reload the symbol files after re-location into RAM, GDB still does not seem to be able to sync up to source code (see transcript below). Also, when I do "mips-linux-objdump -dS u-boot", the result does not include C code mixed w/ ASM. This does work when building u-boot for ARM. Does anyone have any suggestions?

Another strange thing w/ GDB, when I type "break <function name>" the resulting breakpoint is 10 instructions past the start of the function.

Thanks,
Cliff

GDB transcript:

cbrake at notebook ~/workspace/u-boot $ mips-linux-gdb u-boot
Warning: Cannot initialize solib-absolute-prefix
GNU gdb Yellow Dog Linux (5.2.1-4b_8)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i386-redhat-linux --target=mips-linux"... (gdb) symbol-file
Discard symbol table from `/home/cbrake/workspace/u-boot/u-boot'? (y or n) y No symbol file now.
(gdb) add-symbol-file u-boot 0x80fdc000
add symbol table from file "u-boot" at

        .text_addr = 0x80fdc000

(y or n) y
Reading symbols from u-boot...done.
(gdb) target remote bdi:2001
Remote debugging using bdi:2001
0x80fdd158 in ?? ()
(gdb) break printf
Breakpoint 1 at 0x80fe9ecc: file console.c, line 225. (gdb) ni

Program received signal SIGABRT, Aborted.
warning: Warning: GDB can't find the start of the function at 0x80fdd15c.

    GDB is unable to find the start of the function at 0x80fdd15c

and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame, or the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x80fdd15c for code which looks like the beginning of a function, you can increase the range of the search using the `set heuristic-fence-post' command.
0x80fdd15c in ?? ()

=======================
Cliff Brake
http://bec-systems.com

For the record, after upgrading to BDI firmware version V1.11 and gdb version 6.3.50, things are working much better. Still can't single step through ROM with GDB, but after relocating to RAM, everything works as advertised.

As suggested by Andrew Dyer, GDB is skipping the stack frame setup at the beginning of functions.

Cliff

=======================
Cliff Brake
http://bec-systems.com