[U-Boot-Users] debugging U-boot with GDB on a Au1550

[U-Boot-Users] debugging U-boot with GDB on a Au1550

[Cliff Brake]

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

[U-Boot-Users] debugging U-boot with GDB on a Au1550

[Wolfgang Denk]

In message <f96d234e05071614186ad9526a@mail.gmail.com> you wrote:
>
> 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)?

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.

[U-Boot-Users] debugging U-boot with GDB on a Au1550

[Cliff Brake]

On 7/16/05, Wolfgang Denk <wd@denx.de> wrote:
> In message <f96d234e05071614186ad9526a@mail.gmail.com> you wrote:
> >
> > 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)?
> 
> May I suggest that you start reading the manual? Especially section
> http://www.denx.de/twiki/bin/view/DULG/DebuggingUBoot#Section_10.1.2.

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

[U-Boot-Users] debugging U-boot with GDB on a Au1550

[Cliff Brake]

On 7/18/05, Cliff Brake <cliff.brake@gmail.com> wrote:
> On 7/16/05, Wolfgang Denk <wd@denx.de> wrote:
> > In message <f96d234e05071614186ad9526a@mail.gmail.com> you wrote:
> > >
> > > 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)?
> >
> > May I suggest that you start reading the manual? Especially section
> > http://www.denx.de/twiki/bin/view/DULG/DebuggingUBoot#Section_10.1.2.
> 
> 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

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.

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

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

Cliff

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