This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ELF section identification and gld
- From: Ian Lance Taylor <ian at wasabisystems dot com>
- To: "Jan Beulich" <JBeulich at novell dot com>
- Cc: <binutils at sources dot redhat dot com>
- Date: 27 Aug 2004 09:59:17 -0400
- Subject: Re: ELF section identification and gld
- References: <s12ee188.043@emea1-mh.id2.novell.com>
"Jan Beulich" <JBeulich@novell.com> writes:
> Should I file a bug report? I haven't worked with the linker code a
> lot, yet, so I don't feel like I could cheaply derive a fix here.
Sure, file a bug report. Thanks.
> >I think I see what you mean. I am slightly confused by your use of
> >the word "targets." I think I would say "when a relocation in an
> >alloc section refers to a symbol which is defined in a non-alloc
> >section." I agree that that case does not make sense. When does it
> >happen?
>
> I saw it happen together with the other problem. The i386 linux build
> currently may (configuration dependent) lead to ld -r renaming a section
> with the alloc flag clear due to an identically named section in another
> object with the alloc flag set. The linker script later dealing with
> linking all the intermediately (ld -r) created objects into the final
> executable only knows about the un-renamed section, and since the
> renamed one is no-alloc, references from .text to the symbol(s) in this
> section meet this criteria.
> But I could certainly imagine other conditions leading to this that
> could be safe-guarded against by emitting a warning (i.e. a symbol in a
> debug info section incorrectly being referenced from a 'real' one, or
> may be due to discarding an alloc section in the linker script [though I
> don't know how exactly this works - it could either entirely discard the
> section or simply make it no-alloc in the output, and in the former
> there may already be a diagnostic]).
Thanks for the detailed explanation.
Ian