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

[NightStrike]

Ping

On Thu, Sep 29, 2011 at 4:56 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2011/9/29 Alan Modra <amodra@gmail.com>:
>> On Tue, Sep 27, 2011 at 02:37:22PM +0200, Kai Tietz wrote:
>>> diff -u -r1.79 cofflink.c
>>> --- bfd/cofflink.c    17 Aug 2011 00:39:38 -0000      1.79
>>> +++ bfd/cofflink.c    27 Sep 2011 11:21:47 -0000
>>> @@ -2318,7 +2327,9 @@
>>>
>>>        if ((o->flags & SEC_LINKER_CREATED) != 0)
>>>       continue;
>>> -
>>> +      if (!bfd_is_abs_section (o)
>>> +       && o->output_section == bfd_abs_section_ptr)
>>> +     continue;
>>
>> How is it that the earlier o->linker_mark test is not sufficient?
>
> This hunk might be unnecessary.  It is a relic of evolution for
> detecting the underlying issue here.  I didn't noticed the check for
> o->linker_mark test.  I checked and patch with just the next hunk
> works as desired.
>
>>>        if ((o->flags & SEC_HAS_CONTENTS) == 0
>>>         || (o->size == 0 && (o->flags & SEC_RELOC) == 0))
>>>       {
>>> @@ -2386,7 +2397,10 @@
>>>             if (ps == NULL)
>>>               continue;
>>>             /* Complain if definition comes from an excluded section.  */
>>> -           if (ps->flags & SEC_EXCLUDE)
>>> +           if ((ps->flags & SEC_EXCLUDE) != 0
>>> +               && (ps->owner->flags & BFD_PLUGIN) == 0
>>> +               && !bfd_is_abs_section (ps)
>>> +               && bfd_is_abs_section ((ps)->output_section))
>>>               (*finfo->info->callbacks->einfo)
>>>                 (_("%X`%s' referenced in section `%A' of %B: "
>>>                    "defined in discarded section `%A' of %B\n"),
>>
>> 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.
>
> So as intermediate work-a-round for the issue LTO and object-file
> arguments, i think this patch seems to be valid.
>
> Regards,
> Kai
>