* debug problem with prelinked libraries @ 2010-05-05 12:48 Andrew Stubbs 2010-05-05 14:35 ` Daniel Jacobowitz 0 siblings, 1 reply; 17+ messages in thread From: Andrew Stubbs @ 2010-05-05 12:48 UTC (permalink / raw) To: gdb Hi all, I'm trying to get to the bottom of a problem debugging prelinked libraries. I've fixed a few aspects of the problem, but the further I get into it the more I think I must be missing something. I mean, debugging prelinked libraries is supposed to Just Work, right? But I can't see how it could ever have worked. First, I should say that I'm trying to debug a core dump that includes prelinked libraries. Is that different somehow? The target is mips, if that makes any difference. Also, debugging works fine for the non-prelinked libraries and core file, so the problem's not there. I originally encountered the problem with (a somewhat patched) 6.6.50_20070925, but I'm seeing exactly the same trouble in the latest from CVS. The problem is that GDB does not find the symbols and debug info for the code in the prelinked libraries. Upon closer inspection, I find that the psymtab has the textlow and texthigh addresses as the original file-offsets, before relocation. This appears to be because it calculates the section offset as the difference between the actual address and the ELF VMA, but the file is prelinked, so the offset is zero, and the debug info and symbols are then not relocated. So, I inserted a little code to fixup the offset in the psymtab for the prelinked cases, but it now loads the symtab with exactly the same offset troubles. So, I try to fix those, and the problem just moves one step further on. Surely I can't need to implement prelink support from scratch, so I must be missing something? Is there one place that this should be fixed? I think I need to adjust the base address used by the debug info, but I don't know how to do it without also changing the base address used for relocating the binaries. Any other suggestions? Any help would be much appreciated. Andrew ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: debug problem with prelinked libraries 2010-05-05 12:48 debug problem with prelinked libraries Andrew Stubbs @ 2010-05-05 14:35 ` Daniel Jacobowitz 2010-05-05 14:59 ` Andrew Stubbs 0 siblings, 1 reply; 17+ messages in thread From: Daniel Jacobowitz @ 2010-05-05 14:35 UTC (permalink / raw) To: Andrew Stubbs; +Cc: gdb On Wed, May 05, 2010 at 01:48:21PM +0100, Andrew Stubbs wrote: > Hi all, > > I'm trying to get to the bottom of a problem debugging prelinked > libraries. I've fixed a few aspects of the problem, but the further I > get into it the more I think I must be missing something. I mean, > debugging prelinked libraries is supposed to Just Work, right? But I > can't see how it could ever have worked. It definitely works. GDB is even supposed to automatically handle libraries that are prelinked to a different location on disk than they were at runtime, although that's relatively recent, IIRC. > Upon closer inspection, I find that the psymtab has the textlow and > texthigh addresses as the original file-offsets, before relocation. > This appears to be because it calculates the section offset as the > difference between the actual address and the ELF VMA, but the file > is prelinked, so the offset is zero, and the debug info and symbols > are then not relocated. What do you mean by "before relocation"? Are the libraries used to create the core dump prelinked in exactly the same way as the libraries on the host during debug, or not? It should work either way, but they're different cases. If both libraries are identically prelinked, then I would have expected the prelinked libraries to not require relocation. prelink includes code to manipulate the contents of the debug info. I don't know if prelink follows things across to separate debug info files. It doesn't look like it. So if you have that, too, then the separate debug info file should be treated as a not-prelinked copy of the shared library. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: debug problem with prelinked libraries 2010-05-05 14:35 ` Daniel Jacobowitz @ 2010-05-05 14:59 ` Andrew Stubbs 2010-05-07 13:23 ` Jan Kratochvil 0 siblings, 1 reply; 17+ messages in thread From: Andrew Stubbs @ 2010-05-05 14:59 UTC (permalink / raw) To: gdb On 05/05/10 15:32, Daniel Jacobowitz wrote: > On Wed, May 05, 2010 at 01:48:21PM +0100, Andrew Stubbs wrote: >> Hi all, >> >> I'm trying to get to the bottom of a problem debugging prelinked >> libraries. I've fixed a few aspects of the problem, but the further I >> get into it the more I think I must be missing something. I mean, >> debugging prelinked libraries is supposed to Just Work, right? But I >> can't see how it could ever have worked. > > It definitely works. GDB is even supposed to automatically handle > libraries that are prelinked to a different location on disk than they > were at runtime, although that's relatively recent, IIRC. Yes, I see messages about it fixing these up (libc is different, but the interesting libraries are not). >> Upon closer inspection, I find that the psymtab has the textlow and >> texthigh addresses as the original file-offsets, before relocation. >> This appears to be because it calculates the section offset as the >> difference between the actual address and the ELF VMA, but the file >> is prelinked, so the offset is zero, and the debug info and symbols >> are then not relocated. > > What do you mean by "before relocation"? The textlow and texthigh values get set to small values, such as 0x6c0, rather than the run-time relocated values, which are rather larger numbers. The numbers can be corrected by adding the correct offset. > Are the libraries used to create the core dump prelinked in exactly > the same way as the libraries on the host during debug, or not? It > should work either way, but they're different cases. They are the exact same binaries. I copied them to the target myself. > If both libraries are identically prelinked, then I would have > expected the prelinked libraries to not require relocation. prelink > includes code to manipulate the contents of the debug info. Hmmm, well maybe that's it then. Maybe prelink has failed to relocate the debug info in this case? > I don't know if prelink follows things across to separate debug info > files. It doesn't look like it. So if you have that, too, then the > separate debug info file should be treated as a not-prelinked copy of > the shared library. The debug info is not separated, in this case. Andrew ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: debug problem with prelinked libraries 2010-05-05 14:59 ` Andrew Stubbs @ 2010-05-07 13:23 ` Jan Kratochvil 2010-05-07 13:26 ` Andrew Stubbs 2010-07-01 15:43 ` Thomas Schwinge 0 siblings, 2 replies; 17+ messages in thread From: Jan Kratochvil @ 2010-05-07 13:23 UTC (permalink / raw) To: Andrew Stubbs; +Cc: gdb On Wed, 05 May 2010 16:59:36 +0200, Andrew Stubbs wrote: > > prelink includes code to manipulate the contents of the debug info. [...] > Maybe prelink has failed to relocate the debug info in this case? The attached patch should fix it. Although SHT_MIPS_DWARF value should be recognized only for e_machine as EM_MIPS or EM_MIPS_RS3_LE or EM_MIPS_X? Or are there some other rules? Regards, Jan --- prelink/src/dso.c-orig 2010-04-13 16:41:15.000000000 +0200 +++ prelink/src/dso.c 2010-05-07 15:16:25.000000000 +0200 @@ -1381,6 +1381,7 @@ adjust_dso (DSO *dso, GElf_Addr start, G switch (dso->shdr[i].sh_type) { case SHT_PROGBITS: + case SHT_MIPS_DWARF: name = strptr (dso, dso->ehdr.e_shstrndx, dso->shdr[i].sh_name); if (strcmp (name, ".stab") == 0 && adjust_stabs (dso, i, start, adjust)) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: debug problem with prelinked libraries 2010-05-07 13:23 ` Jan Kratochvil @ 2010-05-07 13:26 ` Andrew Stubbs 2010-07-01 15:43 ` Thomas Schwinge 1 sibling, 0 replies; 17+ messages in thread From: Andrew Stubbs @ 2010-05-07 13:26 UTC (permalink / raw) To: Jan Kratochvil; +Cc: gdb On 07/05/10 14:23, Jan Kratochvil wrote: > On Wed, 05 May 2010 16:59:36 +0200, Andrew Stubbs wrote: >>> prelink includes code to manipulate the contents of the debug info. > [...] >> Maybe prelink has failed to relocate the debug info in this case? > > The attached patch should fix it. Yes, I'm just about to post pretty much the exact same patch. :) Andrew ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: debug problem with prelinked libraries 2010-05-07 13:23 ` Jan Kratochvil 2010-05-07 13:26 ` Andrew Stubbs @ 2010-07-01 15:43 ` Thomas Schwinge 2010-07-06 9:59 ` MIPS: 64-bit DWARF (was: debug problem with prelinked libraries) Thomas Schwinge 1 sibling, 1 reply; 17+ messages in thread From: Thomas Schwinge @ 2010-07-01 15:43 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Andrew Stubbs, gdb [-- Attachment #1: Type: text/plain, Size: 2718 bytes --] Hello! On 2010-05-07 13:23, Jan Kratochvil wrote: > On Wed, 05 May 2010 16:59:36 +0200, Andrew Stubbs wrote: >> > prelink includes code to manipulate the contents of the debug info. > [...] >> Maybe prelink has failed to relocate the debug info in this case? > > The attached patch should fix it. > > Although SHT_MIPS_DWARF value should be recognized only for e_machine as > EM_MIPS or EM_MIPS_RS3_LE or EM_MIPS_X? Or are there some other rules? > --- prelink/src/dso.c-orig 2010-04-13 16:41:15.000000000 +0200 > +++ prelink/src/dso.c 2010-05-07 15:16:25.000000000 +0200 > @@ -1381,6 +1381,7 @@ adjust_dso (DSO *dso, GElf_Addr start, G > switch (dso->shdr[i].sh_type) > { > case SHT_PROGBITS: > + case SHT_MIPS_DWARF: > name = strptr (dso, dso->ehdr.e_shstrndx, dso->shdr[i].sh_name); > if (strcmp (name, ".stab") == 0 > && adjust_stabs (dso, i, start, adjust)) Unfortunately, this patch causes the following regression for about every test of the prelink testsuite, in -mabi=64 configurations (only): mips-wrs-linux-gnu-prelink -c ./prelink.conf -C ./prelink.cache --ld-library-path=. --dynamic-linker=./ld.so.1 -vm ./reloc1 Laying out 4 libraries in virtual address space 0000005800000000-0000009800000000 Assigned virtual address space slots for libraries: ./ld.so.1 0000005800000000-0000005800032328 ./libc.so.6 0000005800040000-00000058001cbdb0 ./reloc1lib1.so 00000058001d0000-00000058001e0b10 ./reloc1lib2.so 00000058001f0000-00000058002009d0 Prelinking /scratch/thomas/issue8927/obj/test-4.3a-294-mips-wrs-linux-gnu/host-i686-pc-linux-gnu/mabi_64/prelink.d/ld-2.8.so mips-wrs-linux-gnu-prelink: /scratch/thomas/issue8927/obj/test-4.3a-294-mips-wrs-linux-gnu/host-i686-pc-linux-gnu/mabi_64/prelink.d/ld-2.8.so: 64-bit DWARF not supported mips-wrs-linux-gnu-prelink: Could not prelink ./libc.so.6 because its dependency ./ld.so.1 could not be prelinked mips-wrs-linux-gnu-prelink: Could not prelink ./reloc1lib1.so because its dependency ./libc.so.6 could not be prelinked mips-wrs-linux-gnu-prelink: Could not prelink ./reloc1lib2.so because its dependency ./reloc1lib1.so could not be prelinked mips-wrs-linux-gnu-prelink: Could not prelink ./reloc1 because its dependency ./reloc1lib2.so could not be prelinked I'll try to hunt down where this ``64-bit DWARF not supported'' is coming from, and why handling SHT_MIPS_DWARF in prelink can be responsible for it, but if anyone has any ideas already, please tell me. Regards, Thomas [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* MIPS: 64-bit DWARF (was: debug problem with prelinked libraries) 2010-07-01 15:43 ` Thomas Schwinge @ 2010-07-06 9:59 ` Thomas Schwinge 2010-07-14 8:50 ` MIPS: 64-bit DWARF Thomas Schwinge 0 siblings, 1 reply; 17+ messages in thread From: Thomas Schwinge @ 2010-07-06 9:59 UTC (permalink / raw) To: binutils; +Cc: Jan Kratochvil, Andrew Stubbs, gdb, macro [-- Attachment #1: Type: text/plain, Size: 2879 bytes --] Hello! On 2010-07-01 15:43, I wrote: > On 2010-05-07 13:23, Jan Kratochvil wrote: >> On Wed, 05 May 2010 16:59:36 +0200, Andrew Stubbs wrote: >>> > prelink includes code to manipulate the contents of the debug info. >> [...] >>> Maybe prelink has failed to relocate the debug info in this case? >> >> The attached patch should fix it. >> >> Although SHT_MIPS_DWARF value should be recognized only for e_machine as >> EM_MIPS or EM_MIPS_RS3_LE or EM_MIPS_X? Or are there some other rules? > >> --- prelink/src/dso.c-orig 2010-04-13 16:41:15.000000000 +0200 >> +++ prelink/src/dso.c 2010-05-07 15:16:25.000000000 +0200 >> @@ -1381,6 +1381,7 @@ adjust_dso (DSO *dso, GElf_Addr start, G >> switch (dso->shdr[i].sh_type) >> { >> case SHT_PROGBITS: >> + case SHT_MIPS_DWARF: >> name = strptr (dso, dso->ehdr.e_shstrndx, dso->shdr[i].sh_name); >> if (strcmp (name, ".stab") == 0 >> && adjust_stabs (dso, i, start, adjust)) > > Unfortunately, this patch causes the following regression for about every > test of the prelink testsuite, in -mabi=64 configurations (only): > > mips-wrs-linux-gnu-prelink -c ./prelink.conf -C ./prelink.cache --ld-library-path=. --dynamic-linker=./ld.so.1 -vm ./reloc1 > Laying out 4 libraries in virtual address space 0000005800000000-0000009800000000 > Assigned virtual address space slots for libraries: > ./ld.so.1 0000005800000000-0000005800032328 > ./libc.so.6 0000005800040000-00000058001cbdb0 > ./reloc1lib1.so 00000058001d0000-00000058001e0b10 > ./reloc1lib2.so 00000058001f0000-00000058002009d0 > Prelinking /scratch/thomas/issue8927/obj/test-4.3a-294-mips-wrs-linux-gnu/host-i686-pc-linux-gnu/mabi_64/prelink.d/ld-2.8.so > mips-wrs-linux-gnu-prelink: /scratch/thomas/issue8927/obj/test-4.3a-294-mips-wrs-linux-gnu/host-i686-pc-linux-gnu/mabi_64/prelink.d/ld-2.8.so: 64-bit DWARF not supported This happens when processing .debug_lines, which is generated by GAS. prelink does not support the 64-bit DWARF format. From a quick glance, GDB does, see dwarf2read.c:read_initial_length. MIPS is, per gas/config/tc-mips, the only architecture to override DWARF2_FORMAT (which defaults to 32-bit), and thus possibly can emit 64-bit DWARF code, which it actually does for -mabi=64, see tc-mips.c:mips_dwarf2_format. In <http://sourceware.org/ml/binutils/2002-11/msg00429.html> this 64-bit DWARF format support has originally been added. What's our way forward? Can we switch MIPS back to only using the 32-bit DWARF format (save the IRIX case)? Do we need to extend prelink? As I understand the GCC code, it always uses the 32-bit DWARF format, even for MIPS 64-bit ABIs. Regards, Thomas [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: MIPS: 64-bit DWARF 2010-07-06 9:59 ` MIPS: 64-bit DWARF (was: debug problem with prelinked libraries) Thomas Schwinge @ 2010-07-14 8:50 ` Thomas Schwinge 2010-07-14 16:56 ` David Daney 2010-07-19 20:00 ` Richard Sandiford 0 siblings, 2 replies; 17+ messages in thread From: Thomas Schwinge @ 2010-07-14 8:50 UTC (permalink / raw) To: binutils; +Cc: Jan Kratochvil, Andrew Stubbs, gdb, macro, nathan [-- Attachment #1: Type: text/plain, Size: 4852 bytes --] Hello! This is about switching MIPS from 64-bit to 32-bit DWARF format (as other architectures are doing), for the benefit of prelink. On 2010-07-06 09:59, I wrote: > On 2010-07-01 15:43, I wrote: >> On 2010-05-07 13:23, Jan Kratochvil wrote: >>> On Wed, 05 May 2010 16:59:36 +0200, Andrew Stubbs wrote: >>>> > prelink includes code to manipulate the contents of the debug info. >>> [...] >>>> Maybe prelink has failed to relocate the debug info in this case? >>> >>> The attached patch should fix it. >>> >>> Although SHT_MIPS_DWARF value should be recognized only for e_machine as >>> EM_MIPS or EM_MIPS_RS3_LE or EM_MIPS_X? Or are there some other rules? >> >>> --- prelink/src/dso.c-orig 2010-04-13 16:41:15.000000000 +0200 >>> +++ prelink/src/dso.c 2010-05-07 15:16:25.000000000 +0200 >>> @@ -1381,6 +1381,7 @@ adjust_dso (DSO *dso, GElf_Addr start, G >>> switch (dso->shdr[i].sh_type) >>> { >>> case SHT_PROGBITS: >>> + case SHT_MIPS_DWARF: >>> name = strptr (dso, dso->ehdr.e_shstrndx, dso->shdr[i].sh_name); >>> if (strcmp (name, ".stab") == 0 >>> && adjust_stabs (dso, i, start, adjust)) >> >> Unfortunately, this patch causes the following regression for about every >> test of the prelink testsuite, in -mabi=64 configurations (only): >> >> mips-wrs-linux-gnu-prelink -c ./prelink.conf -C ./prelink.cache --ld-library-path=. --dynamic-linker=./ld.so.1 -vm ./reloc1 >> Laying out 4 libraries in virtual address space 0000005800000000-0000009800000000 >> Assigned virtual address space slots for libraries: >> ./ld.so.1 0000005800000000-0000005800032328 >> ./libc.so.6 0000005800040000-00000058001cbdb0 >> ./reloc1lib1.so 00000058001d0000-00000058001e0b10 >> ./reloc1lib2.so 00000058001f0000-00000058002009d0 >> Prelinking /scratch/thomas/issue8927/obj/test-4.3a-294-mips-wrs-linux-gnu/host-i686-pc-linux-gnu/mabi_64/prelink.d/ld-2.8.so >> mips-wrs-linux-gnu-prelink: /scratch/thomas/issue8927/obj/test-4.3a-294-mips-wrs-linux-gnu/host-i686-pc-linux-gnu/mabi_64/prelink.d/ld-2.8.so: 64-bit DWARF not supported > > This happens when processing .debug_lines, which is generated by GAS. > > prelink does not support the 64-bit DWARF format. From a quick glance, > GDB does, see dwarf2read.c:read_initial_length. > > MIPS is, per gas/config/tc-mips, the only architecture to override > DWARF2_FORMAT (which defaults to 32-bit), and thus possibly can emit > 64-bit DWARF code, which it actually does for -mabi=64, see > tc-mips.c:mips_dwarf2_format. > > In <http://sourceware.org/ml/binutils/2002-11/msg00429.html> this 64-bit > DWARF format support has originally been added. > > What's our way forward? Can we switch MIPS back to only using the 32-bit > DWARF format (save the IRIX case)? Do we need to extend prelink? > > As I understand the GCC code, it always uses the 32-bit DWARF format, > even for MIPS 64-bit ABIs. Here is the patch that I tested for (a non-HEAD version of) binutils. This makes prelink happy, and there are no regressions in the GDB testsuite. (Anything else to test?) I left in the 64-bit stuff for TE_IRIX, as I have no idea about it. Index: gas/config/tc-mips.c =================================================================== --- gas/config/tc-mips.c (revision 291480) +++ gas/config/tc-mips.c (working copy) @@ -15499,20 +15499,16 @@ #endif } +#ifdef TE_IRIX enum dwarf2_format mips_dwarf2_format (void) { if (HAVE_64BIT_SYMBOLS) - { -#ifdef TE_IRIX - return dwarf2_format_64bit_irix; -#else - return dwarf2_format_64bit; -#endif - } + return dwarf2_format_64bit_irix; else return dwarf2_format_32bit; } +#endif int mips_dwarf2_addr_size (void) Index: gas/config/tc-mips.h =================================================================== --- gas/config/tc-mips.h (revision 291480) +++ gas/config/tc-mips.h (working copy) @@ -165,9 +165,13 @@ extern void mips_enable_auto_align (void); #define md_elf_section_change_hook() mips_enable_auto_align() +#ifdef TE_IRIX enum dwarf2_format; extern enum dwarf2_format mips_dwarf2_format (void); -#define DWARF2_FORMAT() mips_dwarf2_format () +# define DWARF2_FORMAT() mips_dwarf2_format () +#else +/* Use GAS' defaults. */ +#endif extern int mips_dwarf2_addr_size (void); #define DWARF2_ADDR_SIZE(bfd) mips_dwarf2_addr_size () Is this approach OK, or is there a real reason to have 64-bit DWARF format on MIPS? If it's OK, then I'll port the patch to binutils HEAD ((unused) asection * added to DWARF2_FORMAT). Regards, Thomas [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: MIPS: 64-bit DWARF 2010-07-14 8:50 ` MIPS: 64-bit DWARF Thomas Schwinge @ 2010-07-14 16:56 ` David Daney 2010-07-14 18:44 ` Maciej W. Rozycki 2010-07-19 20:00 ` Richard Sandiford 1 sibling, 1 reply; 17+ messages in thread From: David Daney @ 2010-07-14 16:56 UTC (permalink / raw) To: Thomas Schwinge Cc: binutils, Jan Kratochvil, Andrew Stubbs, gdb, macro, nathan On 07/14/2010 01:50 AM, Thomas Schwinge wrote: [...] > > Here is the patch that I tested for (a non-HEAD version of) binutils. > This makes prelink happy, and there are no regressions in the GDB > testsuite. (Anything else to test?) I left in the 64-bit stuff for > TE_IRIX, as I have no idea about it. > How was it tested? Have you tested mips64-linux-gnu with -mabi=64? Thanks, David Daney > Index: gas/config/tc-mips.c > =================================================================== > --- gas/config/tc-mips.c (revision 291480) > +++ gas/config/tc-mips.c (working copy) > @@ -15499,20 +15499,16 @@ > #endif > } > > +#ifdef TE_IRIX > enum dwarf2_format > mips_dwarf2_format (void) > { > if (HAVE_64BIT_SYMBOLS) > - { > -#ifdef TE_IRIX > - return dwarf2_format_64bit_irix; > -#else > - return dwarf2_format_64bit; > -#endif > - } > + return dwarf2_format_64bit_irix; > else > return dwarf2_format_32bit; > } > +#endif > > int > mips_dwarf2_addr_size (void) > Index: gas/config/tc-mips.h > =================================================================== > --- gas/config/tc-mips.h (revision 291480) > +++ gas/config/tc-mips.h (working copy) > @@ -165,9 +165,13 @@ > extern void mips_enable_auto_align (void); > #define md_elf_section_change_hook() mips_enable_auto_align() > > +#ifdef TE_IRIX > enum dwarf2_format; > extern enum dwarf2_format mips_dwarf2_format (void); > -#define DWARF2_FORMAT() mips_dwarf2_format () > +# define DWARF2_FORMAT() mips_dwarf2_format () > +#else > +/* Use GAS' defaults. */ > +#endif > > extern int mips_dwarf2_addr_size (void); > #define DWARF2_ADDR_SIZE(bfd) mips_dwarf2_addr_size () > > Is this approach OK, or is there a real reason to have 64-bit DWARF > format on MIPS? If it's OK, then I'll port the patch to binutils HEAD > ((unused) asection * added to DWARF2_FORMAT). > > > Regards, > Thomas ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: MIPS: 64-bit DWARF 2010-07-14 16:56 ` David Daney @ 2010-07-14 18:44 ` Maciej W. Rozycki 2010-07-15 15:48 ` Tom Tromey 2010-07-16 11:22 ` Thomas Schwinge 0 siblings, 2 replies; 17+ messages in thread From: Maciej W. Rozycki @ 2010-07-14 18:44 UTC (permalink / raw) To: David Daney Cc: Thomas Schwinge, binutils, Jan Kratochvil, Andrew Stubbs, gdb, Nathan Sidwell On Wed, 14 Jul 2010, David Daney wrote: > > Here is the patch that I tested for (a non-HEAD version of) binutils. > > This makes prelink happy, and there are no regressions in the GDB > > testsuite. (Anything else to test?) I left in the 64-bit stuff for > > TE_IRIX, as I have no idea about it. > > How was it tested? Have you tested mips64-linux-gnu with -mabi=64? GCC switched to emitting 32-bit DWARF records on the MIPS/Linux/n64 platform a couple of years ago. GDB as of 6.8 didn't cope at all with 64-bit DWARF records that were generated for n64 binaries before the switch (for the MIPS platform, that is -- I'd expect it to work for some others, especially ones that have always been 64-bit like the Alpha) -- the usual symptom was a complete exhaustion of the stack space followed by a crash (tested natively only). I am strongly convinced GAS should follow, for consistency if nothing else, and I am rather surprised both tools were not updated at once. TE_IRIX refers to the original 64-bit DWARF stuff invented by SGI that predates DWARF-3 and differs slightly from the latter. This may perhaps be the reason of the GDB crash -- it may have this SGI variant hardcoded for the MIPS target or suchlike. Having noticed the GCC switch I have not investigated it further. The change needs to be properly tested of course to see if it does not uncover an odd bug somewhere, but in principle I consider it the right and necessary move. Maciej ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: MIPS: 64-bit DWARF 2010-07-14 18:44 ` Maciej W. Rozycki @ 2010-07-15 15:48 ` Tom Tromey 2010-07-16 14:44 ` Maciej W. Rozycki 2010-07-21 22:54 ` Joseph S. Myers 2010-07-16 11:22 ` Thomas Schwinge 1 sibling, 2 replies; 17+ messages in thread From: Tom Tromey @ 2010-07-15 15:48 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: gdb >>>>> "Maciej" == Maciej W Rozycki <macro@codesourcery.com> writes: I trimmed the CCs. Maciej> GDB as of 6.8 didn't cope at all with 64-bit DWARF records that Maciej> were generated for n64 binaries before the switch (for the MIPS Maciej> platform, that is -- I'd expect it to work for some others, Maciej> especially ones that have always been 64-bit like the Alpha) -- Maciej> the usual symptom was a complete exhaustion of the stack space Maciej> followed by a crash (tested natively only). Could you try a newer gdb? And, if it still fails, file a bug report? gdb isn't fully ready for 64 bit DWARF (e.g., CU offsets are still just unsigned ints), but it shouldn't crash. Maciej> TE_IRIX refers to the original 64-bit DWARF stuff invented by Maciej> SGI that predates DWARF-3 and differs slightly from the latter. Maciej> This may perhaps be the reason of the GDB crash -- it may have Maciej> this SGI variant hardcoded for the MIPS target or suchlike. gdb's dwarf reader doesn't use the target for this. It just recognizes the SGI approach unconditionally. See dwarf2read.c:read_initial_length. Tom ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: MIPS: 64-bit DWARF 2010-07-15 15:48 ` Tom Tromey @ 2010-07-16 14:44 ` Maciej W. Rozycki 2010-07-21 22:54 ` Joseph S. Myers 1 sibling, 0 replies; 17+ messages in thread From: Maciej W. Rozycki @ 2010-07-16 14:44 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb On Thu, 15 Jul 2010, Tom Tromey wrote: > Maciej> GDB as of 6.8 didn't cope at all with 64-bit DWARF records that > Maciej> were generated for n64 binaries before the switch (for the MIPS > Maciej> platform, that is -- I'd expect it to work for some others, > Maciej> especially ones that have always been 64-bit like the Alpha) -- > Maciej> the usual symptom was a complete exhaustion of the stack space > Maciej> followed by a crash (tested natively only). > > Could you try a newer gdb? And, if it still fails, file a bug report? I'm not ready for an upgrade at the moment, sorry. I'll try to remember to test this stuff when I am -- I keep old toolchains around, so I may be able to get a test case easily. I would have debugged the problem originally myself, but obviously GDB crashed with 64-bit-annotated GDB as it did with any other binary. > gdb isn't fully ready for 64 bit DWARF (e.g., CU offsets are still just > unsigned ints), but it shouldn't crash. Well, it recursed till the end of the stack, at which point IIRC the kernel would kill the process. So a resource exhaustion rather a usual segfault or suchlike, though the end result was effectively the same. Clearly it must have got rather confused, but with the immaturity of the n64 toolchain back when I started looking into it that could have been anything up to a compiler or binutils bug. > Maciej> TE_IRIX refers to the original 64-bit DWARF stuff invented by > Maciej> SGI that predates DWARF-3 and differs slightly from the latter. > Maciej> This may perhaps be the reason of the GDB crash -- it may have > Maciej> this SGI variant hardcoded for the MIPS target or suchlike. > > gdb's dwarf reader doesn't use the target for this. It just recognizes > the SGI approach unconditionally. See dwarf2read.c:read_initial_length. I see. Somehow I thought there were some target-dependent hooks involved as well. Thanks for your clarification. Maciej ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: MIPS: 64-bit DWARF 2010-07-15 15:48 ` Tom Tromey 2010-07-16 14:44 ` Maciej W. Rozycki @ 2010-07-21 22:54 ` Joseph S. Myers 2010-07-22 5:28 ` Tom Tromey 1 sibling, 1 reply; 17+ messages in thread From: Joseph S. Myers @ 2010-07-21 22:54 UTC (permalink / raw) To: Tom Tromey; +Cc: Maciej W. Rozycki, gdb On Thu, 15 Jul 2010, Tom Tromey wrote: > >>>>> "Maciej" == Maciej W Rozycki <macro@codesourcery.com> writes: > > I trimmed the CCs. > > Maciej> GDB as of 6.8 didn't cope at all with 64-bit DWARF records that > Maciej> were generated for n64 binaries before the switch (for the MIPS > Maciej> platform, that is -- I'd expect it to work for some others, > Maciej> especially ones that have always been 64-bit like the Alpha) -- > Maciej> the usual symptom was a complete exhaustion of the stack space > Maciej> followed by a crash (tested natively only). > > Could you try a newer gdb? And, if it still fails, file a bug report? > > gdb isn't fully ready for 64 bit DWARF (e.g., CU offsets are still just > unsigned ints), but it shouldn't crash. I fixed problems with GCC's 64-bit DWARF output with <http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01152.html> and switched to 32-bit output with <http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00142.html>. There won't have been many compilers that produced correct 64-bit DWARF for this target, rather than broken 64-bit DWARF or correct 32-bit DWARF. (And, yes, GDB had a propensity to crash then on broken DWARF debug info, and I'm not aware of it since having been fixed to handle broken debug info robustly.) -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: MIPS: 64-bit DWARF 2010-07-21 22:54 ` Joseph S. Myers @ 2010-07-22 5:28 ` Tom Tromey 0 siblings, 0 replies; 17+ messages in thread From: Tom Tromey @ 2010-07-22 5:28 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Maciej W. Rozycki, gdb >>>>> "Joseph" == Joseph S Myers <joseph@codesourcery.com> writes: Joseph> (And, yes, GDB had a propensity to crash then on broken DWARF Joseph> debug info, and I'm not aware of it since having been fixed to Joseph> handle broken debug info robustly.) There have been a couple of robustness fixes in recent times, but not for anything that might have caused a crash. For future reference, I'm happy to fix this sort of problem, but I would need a test case. An object file of whatever form should be fine. I'd imagine these bugs go unfound just because it is unusual to come across DWARF that is bad in just the right way. Tom ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: MIPS: 64-bit DWARF 2010-07-14 18:44 ` Maciej W. Rozycki 2010-07-15 15:48 ` Tom Tromey @ 2010-07-16 11:22 ` Thomas Schwinge 1 sibling, 0 replies; 17+ messages in thread From: Thomas Schwinge @ 2010-07-16 11:22 UTC (permalink / raw) To: Maciej W. Rozycki, David Daney Cc: binutils, Jan Kratochvil, Andrew Stubbs, gdb, Nathan Sidwell [-- Attachment #1: Type: text/plain, Size: 1781 bytes --] Hello! On 2010-07-14 18:44, Maciej W. Rozycki wrote: > On Wed, 14 Jul 2010, David Daney wrote: >> > Here is the patch that I tested for (a non-HEAD version of) binutils. >> > This makes prelink happy, and there are no regressions in the GDB >> > testsuite. (Anything else to test?) I left in the 64-bit stuff for >> > TE_IRIX, as I have no idea about it. >> >> How was it tested? I developed / applied the patch using a tree with non-HEAD sources, and (re-)built a complete mips-linux-gnu toolchain (GCC has been built with ``--enable-mips-nonpic --with-arch32=4kc --with-arch64=5kf''), then ran all binutils and GDB regression test suites for the following multilibs / switches, and compared to baseline sources: ".;" ".;@mabi=64" "mel;@mel" "hard-float;@mhard-float" "hard-float;@mhard-float@mabi=n32" "hard-float;@mhard-float@mabi=64" "hard-float/vr5500;@mhard-float@march=vr5500" "mel/hard-float;@mel@mhard-float" "mel/hard-float;@mel@mhard-float@mabi=n32" "mel/hard-float;@mel@mhard-float@mabi=64" "octeon;@march=octeon@mabi=n32" "octeon;@march=octeon@mabi=64" "octeon2;@march=octeon2@mabi=n32" "octeon2;@march=octeon2@mabi=64" "uclibc;@muclibc" "uclibc/mel;@muclibc@mel" >> Have you tested mips64-linux-gnu with -mabi=64? I've now running the same testing on HEAD sources for a mips64el-linux-gnu toolchain for: ".;" ".;@mabi=32" ".;@mabi=64" I'll post the results once that's finished. > The change needs to be properly tested of course to see if it does not > uncover an odd bug somewhere, but in principle I consider it the right and > necessary move. Is there anything else I should be testing? Regards, Thomas [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: MIPS: 64-bit DWARF 2010-07-14 8:50 ` MIPS: 64-bit DWARF Thomas Schwinge 2010-07-14 16:56 ` David Daney @ 2010-07-19 20:00 ` Richard Sandiford 2010-07-22 7:41 ` Thomas Schwinge 1 sibling, 1 reply; 17+ messages in thread From: Richard Sandiford @ 2010-07-19 20:00 UTC (permalink / raw) To: Thomas Schwinge Cc: binutils, Jan Kratochvil, Andrew Stubbs, gdb, macro, nathan Thomas Schwinge <thomas@codesourcery.com> writes: > Here is the patch that I tested for (a non-HEAD version of) binutils. > This makes prelink happy, and there are no regressions in the GDB > testsuite. (Anything else to test?) I left in the 64-bit stuff for > TE_IRIX, as I have no idea about it. Patch is OK with the testing you described downstream, and with a suitable changelog. Just to be sure, would you mind checking the "binutils" (including gas and ld) testresults for both mips64-linux-gnu and mips64el-linux-gnu? There's no need to test multilibs; just run both without any test options. Thanks, Richard ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: MIPS: 64-bit DWARF 2010-07-19 20:00 ` Richard Sandiford @ 2010-07-22 7:41 ` Thomas Schwinge 0 siblings, 0 replies; 17+ messages in thread From: Thomas Schwinge @ 2010-07-22 7:41 UTC (permalink / raw) To: binutils; +Cc: Jan Kratochvil, Andrew Stubbs, gdb, macro, nathan, rdsandiford [-- Attachment #1: Type: text/plain, Size: 996 bytes --] On 2010-07-19 20:00, Richard Sandiford wrote: > Thomas Schwinge <thomas@codesourcery.com> writes: >> Here is the patch that I tested for (a non-HEAD version of) binutils. >> This makes prelink happy, and there are no regressions in the GDB >> testsuite. (Anything else to test?) I left in the 64-bit stuff for >> TE_IRIX, as I have no idea about it. > > Patch is OK with the testing you described downstream, and with a > suitable changelog. Just to be sure, would you mind checking the > "binutils" (including gas and ld) testresults for both mips64-linux-gnu > and mips64el-linux-gnu? There's no need to test multilibs; just run > both without any test options. Done (had this in my testing schedule already, but forgot to say so); no regressions. 2010-07-22 Thomas Schwinge <thomas@codesourcery.com> Switch MIPS to 32-bit DWARF format. * config/tc-mips.h (DWARF2_FORMAT): Only define for [TE_IRIX]. * config/tc-mips.c (mips_dwarf2_format): Likewise. Committed. Regards, Thomas [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2010-07-22 7:41 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-05-05 12:48 debug problem with prelinked libraries Andrew Stubbs 2010-05-05 14:35 ` Daniel Jacobowitz 2010-05-05 14:59 ` Andrew Stubbs 2010-05-07 13:23 ` Jan Kratochvil 2010-05-07 13:26 ` Andrew Stubbs 2010-07-01 15:43 ` Thomas Schwinge 2010-07-06 9:59 ` MIPS: 64-bit DWARF (was: debug problem with prelinked libraries) Thomas Schwinge 2010-07-14 8:50 ` MIPS: 64-bit DWARF Thomas Schwinge 2010-07-14 16:56 ` David Daney 2010-07-14 18:44 ` Maciej W. Rozycki 2010-07-15 15:48 ` Tom Tromey 2010-07-16 14:44 ` Maciej W. Rozycki 2010-07-21 22:54 ` Joseph S. Myers 2010-07-22 5:28 ` Tom Tromey 2010-07-16 11:22 ` Thomas Schwinge 2010-07-19 20:00 ` Richard Sandiford 2010-07-22 7:41 ` Thomas Schwinge
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).