[PATCH 5/5] PR ld/20828: Reorder the symbol sweep stage of section GC

[Alan Modra]

On Wed, Jan 25, 2017 at 11:51:34PM +0000, Maciej W. Rozycki wrote:
> --- binutils.orig/bfd/elflink.c	2017-01-25 22:35:51.360905740 +0000
> +++ binutils/bfd/elflink.c	2017-01-25 23:05:51.315467007 +0000
> @@ -667,7 +667,12 @@ bfd_elf_record_link_assignment (bfd *out
>    if (provide
>        && h->def_dynamic
>        && !h->def_regular)
> -    h->root.type = bfd_link_hash_undefined;
> +    {
> +      if (h->ref_regular)
> +	h->root.type = bfd_link_hash_undefined;
> +      else
> +	return TRUE;
> +    }
>  
>    /* If this symbol is not being provided by the linker script, and it is
>       currently defined by a dynamic object, but not by a regular object,

After thinking about this some more, I'm inclined to say the intent of
PROVIDE was to define the symbol if referenced from either static or
dynamic objects.  So how do you tell if a symbol is referenced from a
dynamic object?  You can't exactly, short of decompiling the code, but
if the dynamic object contains a dynamic undefined symbol then I'd say
that should count as a reference.  What about a dynamic defined
symbol?  Well, if it is default visibility then a dynamic defined
symbol will be overridden by a symbol defined in the executable.  I
think that means we need to count dynamic definitions as potential
references too.

If a defined dynamic symbol is non-default visibility then clearly the
dynamic object can't reference another symbol of the same name in the
executable (ignoring HJ's horrible protected copies).  So we do have a
bug, but not the one you're "fixing" here.

It might be reasonable to change the meaning of PROVIDE to define the
symbol only if referenced from static objects, but that needs a
different patch.  Also, be prepared for howls of outrage.  :)

-- 
Alan Modra
Australia Development Lab, IBM