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

Kai Tietz ktietz70@googlemail.com
Sat Oct 8 13:43:00 GMT 2011


2011/10/8 Kai Tietz <ktietz70@googlemail.com>:
> 2011/10/6 Alan Modra <amodra@gmail.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.
>
> Well, the point here is that we don't want to warn about discarded
> sections here in some cases.  I see that we miss for non-IR sections
> to check for finfo->info->strip_discarded, as this means we won't have
> duplicates.  So a symbol from IR won't be written out (and here might
> be another issue in write-symbol, too), and therefore it isn't double
> defined.
>
> Secondly it seems to be not correct to check here for EXCLUDED flag,
> instead we should look always for section being no abs-one, and
> output-section being an abs-section.
> As if SEC_EXCLUDED is set, the output-section is always set to
> abs-section.  So check logic is more equal to ELF.
>
> Alter patch attached. I did a regression test for x86_64-w64-mingw32,
> i686-w64-mingw, and i686-pc-cygwin.
>
> Regards,
> Kai
>
> Index: cofflink.c
> ===================================================================
> RCS file: /cvs/src/src/bfd/cofflink.c,v
> retrieving revision 1.79
> diff -u -r1.79 cofflink.c
> --- cofflink.c  17 Aug 2011 00:39:38 -0000      1.79
> +++ cofflink.c  8 Oct 2011 10:33:37 -0000
> @@ -2380,13 +2391,23 @@
>              while (h->root.type == bfd_link_hash_indirect
>                     || h->root.type == bfd_link_hash_warning)
>                h = (struct coff_link_hash_entry *) h->root.u.i.link;
> +             if ((h->root.type == bfd_link_hash_defined
> +                  || h->root.type == bfd_link_hash_defweak)
> +                 && ((finfo->info->strip_discarded
> +                      && h->root.u.def.section != NULL
> +                      && !bfd_is_abs_section (h->root.u.def.section)
> +                      && bfd_is_abs_section (h->root.u.def.section->output_section))
> +                     || (h->root.u.def.section->owner != NULL
> +                         && (h->root.u.def.section->owner->flags &
> BFD_PLUGIN) != 0)))
> +                continue;
>              if (h->root.type == bfd_link_hash_defined
>                  || h->root.type == bfd_link_hash_defweak)
>                ps = h->root.u.def.section;
>              if (ps == NULL)
>                continue;
>              /* Complain if definition comes from an excluded section.  */
> -             if (ps->flags & SEC_EXCLUDE)
> +             if (!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"),
>

Well, without

> +                     || (h->root.u.def.section->owner != NULL
> +                         && (h->root.u.def.section->owner->flags & BFD_PLUGIN) != 0)))

it works too.  So checking here for plugin IR seems to be unnecessary.

Kai



More information about the Binutils mailing list