This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ELF section identification and gld


"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]