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

[Kai Tietz <ktietz70 at googlemail dot com>]

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