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

[NightStrike <nightstrike at gmail dot com>]

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
>