Re: [patch bfd]: Adjust handling for plugin-generated sections for pe-coff targets

[Alan Modra <amodra at gmail dot com>]

On Tue, Oct 04, 2011 at 08:50:20AM -0400, NightStrike wrote:
> Ping

I've been away..

> On Thu, Sep 29, 2011 at 4:56 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
> > 2011/9/29 Alan Modra <amodra@gmail.com>:
> >> I think this is wrong.  You should never be applying a relocation
> >> against a symbol defined in an IR section.  If you are, then either ld
> >> has failed to redefine the symbol properly when given a real
> >> definition in LTO output, or gcc has failed to supply the real
> >> definition.  Either way, you shouldn't hide this error.
> >
> > Well, it might be wrong, if we assume that all objects are seen by IR.
> >  That isn't the case for now.  By this it happens (I can sent you test
> > for this issue offline - it is a bit too big and complex to do for it
> > a binutils testcase, if you are intetested) in cases that within a
> > used library the same object (call it x) as additional specified on
> > command-line is specified.  Here the object-file x on command-line
> > gets resolved later, so that IR assumes it has an IRONLY symbol from
> > its library version of x, but later on when the object x from
> > command-line is finally linked, the IR version of x is getting
> > discarded.  By this any function reference in library to a symbol of
> > library's object x version, are pointing to discarded version,  This
> > doesn't cause troubles, as on final linking the already linked
> > object-references are used instead.  Actually they aren't
> > multiple-times linked, just once.

Your argument hasn't convinced me to approve your patch.  I still
believe it is wrong to ignore *all* relocs against symbols defined in
IR sections, as your patch does.  It might be reasonable to ignore
some, as the ELF linker does for relocs in debug or other special
handled sections.

-- 
Alan Modra
Australia Development Lab, IBM