Re: gdb for egcs/sh-elf

[Ralf Corsepius <corsepiu@faw.uni-ulm.de>]

Stan Shebs wrote:

> Ralf Corsepius <corsepiu@faw.uni-ulm.de> writes:
>
> > But if trying to debug things are going to be strange: gdb doesn't seem
> > to find the correct location of functions.
>
> Probably the compiler is issuing some bogus debug info, or perhaps not
> issuing it at all.  Use -save-temps to see if the assembly code includes
> debugging-related directives; you should see mentions of line numbers,

It looks like relocatible object files are not handled correctly for
--target=sh-elf, while they are handled correctly fotr  --target=sh-coff.

Finally I've been able to reproduce my problem using a small test program
running on gdb's sh-simulator (sources attached to this mail)

Compiled for  sh-elf (egcs-1.0.1) the test result looks like (gdb printout)

> 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=i586-pc-linux-gnulibc1 --target=sh-elf".

> start address 0x4000
> Transfer rate: 29168 bits in <1 sec.
> Loading section .text, size 0xb20 lma 0x4000
> Loading section .rodata, size 0x1a lma 0x4b20
> Loading section .data, size 0x300 lma 0x4bbc
> Loading section .stack, size 0x4 lma 0x1ffe0
> Start address 0x4000
> Transfer rate: 29168 bits in <1 sec.
> Breakpoint 1 at 0x4048: file app.c, line 7.
> Breakpoint 2 at 0x40a2
> Breakpoint 3 at 0x40a4: file blue.c, line 7.

==> Breakpoint 2 isn't found by gdb (in this case gdb-980122, but also
reproduceable with gdb-4.16).

Compiled for sh-coff (egcs-1.0.1 or gcc-2.7.3.3) the test runs correctly:

> GDB is free software and you are welcome to 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.
> GDB 4.16 (i586-pc-linux-gnulibc1 --target sh-coff),
> Copyright 1996 Free Software Foundation, Inc.
> Connected to the simulator.
> Loading section .text, size 0xba0 vma 0x4000
> Loading section .data, size 0x330 vma 0x4c20
> Loading section .stack, size 0x10 vma 0x1ffe0
> Breakpoint 1 at 0x4054: file app.c, line 7.
> Breakpoint 2 at 0x40b8: file red.c, line 7.
> Breakpoint 3 at 0x40d8: file blue.c, line 7.

==> All breakpoints are found correctly (with gdb-980122 and gdb-4.16)

> > Is it my linker script, the debugging stub on the target, binutils, egcs
> > or gdb ?
>
> With just the info you've supplied here, it could be any part of the
> toolchain.  If you isolate it down to an EGCS, binutils, or GDB problem,
> please collect all the relevant bits (your source code, linker script,
> command transcript, etc), and pass it along to the appropriate bug
> reporting list.  crossgcc@cygnus.com also has a number of people
> that might have some helpful suggestions.

I don't know enough about gdb's/libbfd internals to fix this problem myself,
but probably some gdb/libbfd/ld/gcc etc. expert might fix this problem.

My environment:
host: i586-pc-linux-gnulibc1,
target (sh-elf/sh-coff) : egcs-1.0.1, gas-980123/binutils-2.8.1.0.19,
gdb-4.16/gdb-980122, newlib-1.8.0 with rtems-patches compiled with a one-tree
script modified for egcs and gdb.

Regard,

Ralf.

PS.: Please excuse that I am cross-posting this to several xxx@cygnus.com
addresses, but I simply don't know which is the right address to send this
mail to.