From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ralf Corsepius To: Stan Shebs Cc: crossgcc@cygnus.com, amylaar@cygnus.com, bfd@cygnus.com, gas2@cygnus.com Subject: Re: gdb for egcs/sh-elf Date: Sun, 25 Jan 1998 08:46:00 -0000 Message-id: <34CB6C1A.13681888@faw.uni-ulm.de> References: <34BCDF46.2424957B@faw.uni-ulm.de> X-SW-Source: 1998/msg00007.html Stan Shebs wrote: > Ralf Corsepius 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.