Re: ld segfault on incrementally linked object

Re: ld segfault on incrementally linked object

[amodra]

On Mon, May 14, 2001 at 02:01:39PM -0700, Ian Thompson wrote:
> 
> dwarf1.c:593: structure has no member named 'debug_relocate'
> dwarf1.c:595: structure has no member named 'debug_relocate'
> dwarf1.c:612: structure has no member named 'debug_relocate'
> 
> Did I miss something?  Where is this member supposed to be declared?

No, I missed something.  Sorry, only diffed bfd/ directory.

include/ChangeLog
	* bfdlink.h (struct bfd_link_info): Add debug_relocate.


Index: include/bfdlink.h
===================================================================
RCS file: /cvs/src/src/include/bfdlink.h,v
retrieving revision 1.9
diff -u -p -r1.9 bfdlink.h
--- bfdlink.h	2001/04/13 00:34:36	1.9
+++ bfdlink.h	2001/05/15 02:57:44
@@ -217,6 +217,9 @@ struct bfd_link_info
      select an appropriate memset function.  Apparently it is also
      normal for HPPA shared libraries to have undefined symbols.  */
   boolean allow_shlib_undefined;
+  /* true if the section being relocated is debug info, and undefined
+     sym error messages should be suppressed.  */
+  boolean debug_relocate;
   /* Which symbols to strip.  */
   enum bfd_link_strip strip;
   /* Which local symbols to discard.  */

Re: ld segfault on incrementally linked object

[amodra]

On Wed, May 16, 2001 at 11:49:21AM -0700, Ian Thompson wrote:
> Sorry to keep bothering you, but I also noticed that I am seeing similar
> problems with the debug info when looking at it with the newest GDB
> release.  Would I be correct in assuming that it's unlikely for this to
> be a debugger problem?  

Strictly speaking, it is a debugger problem, but it's one that the
linker may need to work around.  Let's see if I can explain.

ELF object files have a number of sections, code (.text), data, rodata
etc., and each of these sections may have a corresponding relocation
section containing a number of relocation records.  A relocation
record consists of four piece of information, its type, the symbol we
are relocating against, an addend to the symbol, and the offset within
the code/data section where the reloc applies.  When an object file is
linked into an executable, both the section and it's relocation section
must be consulted to determine the final result.  You might think
addends would only rarely be used, but gas on many targets translates
relocations against local syms to a relocation against the start of
the local symbol's section plus the appropriate addend.  That way, you
don't need to keep huge numbers of local syms in a symbol table.

To complicate matters, there are two types of relocation, REL, where
the relocation addend is stored in the code/data section in the same
place as the reloc applies, and RELA, where the relocation addend is
stored in the relocation section.  For RELA relocs, the linker can
(and does) ignore the data in the section where the relocation applies.
We use this fact when doing a "ld -r" on sections with RELA relocs,
and just update all the relocation addends that are against the start
of a section.  We don't bother applying relocations to the section
data, as whatever is there is irrelevant.  Or at least it would be
irrelevant if the world were an ideal place.  Unfortunately, gdb and
other debuggers (and even binutils itself) read the raw data from
debug sections without applying the relocs.

-- 
Alan Modra

Re: ld segfault on incrementally linked object

[amodra]

On Sat, May 12, 2001 at 12:07:04PM -0700, Geoff Keating wrote:
> > From: amodra@one.net.au
> > Sooo, either the above quoted comment is wrong and we do need to
> > perform section relocations for incremental linking, or dwarf1.c
> > needs to relocate debug info.  I don't particularly like the second
> > option for a number of reasons.
> 
> The second option is the correct one.  If there's a reloc, and we are
> using RELA relocs, the data at the reloc can be anything.

Yeah, but it's a pain.  Here's a first pass that works for the common
case of reporting errors during a final link.  It would be possible to
flesh out _bfd_dwarf_get_relocated_section_contents with various bits
of code stolen from elflink.h in case finfo is not available, but that
could get tricky.  eg. If .debug is not going to be output, and thus
does not have an output_section, then how do you dig up the output bfd?

-- 
Alan Modra

Re: ld segfault on incrementally linked object

[Geoff Keating]

> From: amodra@one.net.au
> Date: Sat, 12 May 2001 23:22:46 +0930

> elf32-ppc.c:ppc_elf_relocate_section (and other rela targets) say this
> about incremental/relocatable linking:
> 
> 	  /* This is a relocateable link.  We don't have to change
> 	     anything, unless the reloc is against a section symbol,
> 	     in which case we have to adjust according to where the
> 	     section symbol winds up in the output section.  */
> 
> That's mostly right too, as the section data with the reloc will be
> replaced during final link.  What we have in the section doesn't
> matter too much.  However, dwarf1.c:_bfd_dwarf1_find_nearest_line,
> which is called when the linker hits an undefined symbol, reads the
> _unrelocated_ .debug data to determine which line of code referenced
> the symbol.  In particular, the low_pc and high_pc bounds on line
> debug info are read, and need to be relocated before they can be used
> correctly.
> 
> Sooo, either the above quoted comment is wrong and we do need to
> perform section relocations for incremental linking, or dwarf1.c
> needs to relocate debug info.  I don't particularly like the second
> option for a number of reasons.

The second option is the correct one.  If there's a reloc, and we are
using RELA relocs, the data at the reloc can be anything.

Even if we changed this for GNU ld, it would just make it incompatible
with other vendors' ways of generating ELF .o files.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: ld segfault on incrementally linked object

[amodra]

elf32-ppc.c:ppc_elf_relocate_section (and other rela targets) say this
about incremental/relocatable linking:

	  /* This is a relocateable link.  We don't have to change
	     anything, unless the reloc is against a section symbol,
	     in which case we have to adjust according to where the
	     section symbol winds up in the output section.  */

That's mostly right too, as the section data with the reloc will be
replaced during final link.  What we have in the section doesn't
matter too much.  However, dwarf1.c:_bfd_dwarf1_find_nearest_line,
which is called when the linker hits an undefined symbol, reads the
_unrelocated_ .debug data to determine which line of code referenced
the symbol.  In particular, the low_pc and high_pc bounds on line
debug info are read, and need to be relocated before they can be used
correctly.

Sooo, either the above quoted comment is wrong and we do need to
perform section relocations for incremental linking, or dwarf1.c
needs to relocate debug info.  I don't particularly like the second
option for a number of reasons.

dwarf2.c has the same problem.

Comments?

-- 
Alan Modra

Re: ld segfault on incrementally linked object

[Ryan Bedwell (ra9407)]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

Alan,

Attached is a tarball with the requested object files and a makefile. 
The makefile assumes that powerpc-eabi-ld is in the path.  The two
object files come from Michael J. Haertel's malloc library
implementation.

Here are the configure options which I used in building binutils:

./configure --prefix=$(HOME) --target=powerpc-eabi

Ryan

amodra@one.net.au wrote:
> 
> On Thu, May 10, 2001 at 10:16:00PM -0500, Ryan Bedwell (ra9407) wrote:
> > I'm seeing a bit of strange behavior: I'm getting ld segfaults, and I've
> > narrowed it down to unresolved symbols in an object file which was
> > created by incrementally linking several other object files.  However,
> > if I specify the source object files rather than the incrementally
> > linked file, it correctly reports the unresolved symbols and exits.
> 
> I'll take a look if you send me
>  a) The configure options you used when building binutils,
>  b) a set of (preferably small) object files that exhibit the problem,
>  c) a script or makefile to produce the incrementally linked intermediate
>     and final ld segfault.
> 
> --
> Alan Modra
ld_segfault.tar.gz


[-- Attachment #2: ld_segfault.tar.gz --]
[-- Type: application/x-gzip, Size: 2130 bytes --]

Re: ld segfault on incrementally linked object

[amodra]

On Thu, May 10, 2001 at 10:16:00PM -0500, Ryan Bedwell (ra9407) wrote:
> I'm seeing a bit of strange behavior: I'm getting ld segfaults, and I've
> narrowed it down to unresolved symbols in an object file which was
> created by incrementally linking several other object files.  However,
> if I specify the source object files rather than the incrementally
> linked file, it correctly reports the unresolved symbols and exits.

I'll take a look if you send me
 a) The configure options you used when building binutils,
 b) a set of (preferably small) object files that exhibit the problem,
 c) a script or makefile to produce the incrementally linked intermediate
    and final ld segfault.

-- 
Alan Modra

ld segfault on incrementally linked object

[Ryan Bedwell (ra9407)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2747 bytes --]

Hello!

I'm seeing a bit of strange behavior: I'm getting ld segfaults, and I've
narrowed it down to unresolved symbols in an object file which was
created by incrementally linking several other object files.  However,
if I specify the source object files rather than the incrementally
linked file, it correctly reports the unresolved symbols and exits.

I've seen this in the 2.10 and 2.10.1 binutils releases (I'm
cross-compiling for a powerpc-eabi target with dwarf debugging info from
a Sun Solaris host).  Here's a gdb stack trace from the failure (2.10.1
sources):

Program received signal SIGSEGV, Segmentation fault.
bfd_getb16 (addr=0x2745d9 <Address 0x2745d9 out of bounds>) at
libbfd.c:925
925       return (addr[0] << 8) | addr[1];
(gdb) where
#0  bfd_getb16 (addr=0x2745d9 <Address 0x2745d9 out of bounds>) at
libbfd.c:925
#1  0x555f4 in parse_die (abfd=0xb9388, aDieInfo=0xffbeefa0, 
    aDiePtr=0x2745db <Address 0x2745db out of bounds>) at dwarf1.c:211
#2  0x55930 in parse_functions_in_unit (stash=0xc3a08, aUnit=0xc3a50)
    at dwarf1.c:357
#3  0x55a3c in dwarf1_unit_find_nearest_line (stash=0xc3a08,
aUnit=0xc3a50, 
    addr=300, filename_ptr=0xffbef1cc, functionname_ptr=0xffbef1c8, 
    linenumber_ptr=0xffbef1c4) at dwarf1.c:414
#4  0x55c18 in _bfd_dwarf1_find_nearest_line (abfd=0xb9388,
section=0xc07c0, 
    symbols=0x1b2df0, offset=300, filename_ptr=0xffbef1cc, 
    functionname_ptr=0xffbef1c8, linenumber_ptr=0xffbef1c4) at
dwarf1.c:562
#5  0x527cc in _bfd_elf_find_nearest_line (abfd=0xb9388,
section=0xbdec0, 
    symbols=0x1b2df0, offset=300, filename_ptr=0xffbef1cc, 
    functionname_ptr=0xffbef1c8, line_ptr=0xffbef1c4) at elf.c:4783
#6  0x2d278 in vfinfo (fp=0xa5d40, 
    fmt=0x822ca ": undefined reference to `%T'\n", arg=0xffbef3dc)
    at ldmisc.c:305
#7  0x2d784 in einfo (fmt=0x822c8 "%C: undefined reference to `%T'\n")
    at ldmisc.c:455
#8  0x2a350 in undefined_symbol (info=0xa5000, 
    name=0xc1026 "mpc8260_icache_state", abfd=0xb9388, section=0xbdec0, 
    address=300, fatal=true) at ./ldmain.c:1207
#9  0x401f0 in ppc_elf_relocate_section (output_bfd=0xae330,
info=0xa5b98, 
    input_bfd=0xb9388, input_section=0xbdec0, 
    contents=0x1630b8 "\224!ÿà|\b\002¦\223A", relocs=0xc26ec, 
    local_syms=0x1abcb0, local_sections=0x1b0dc8) at elf32-ppc.c:3117
#10 0x49f5c in elf_link_input_bfd (finfo=0xffbef600, input_bfd=0xb9388)
    at elflink.h:5489
#11 0x48464 in bfd_elf32_bfd_final_link (abfd=0xae330, info=0xa5b98)
    at elflink.h:4392
#12 0x4b598 in _bfd_elf32_gc_common_final_link (abfd=0xae330,
info=0xa5b98)
    at elflink.h:6677
#13 0x2aef8 in ldwrite () at ldwrite.c:519
#14 0x28edc in main (argc=530432, argv=0xffbef80c) at ./ldmain.c:367
(gdb) 
 
Any ideas?

Thanks,

Ryan