PPC: undefweak dynamic relocs

[Alan Modra]

On Wed, May 05, 2021 at 01:13:24PM -0700, Fangrui Song wrote:
> > @@ -9808,7 +9808,11 @@ allocate_dynrelocs (struct elf_link_hash_entry *h, void *inf)
> > 	 relocs against symbols which are not dynamic.  */
> >       else if (h->type != STT_GNU_IFUNC)
> > 	{
> > -	  if (h->dynamic_adjusted
> > +	  if ((h->dynamic_adjusted
> > +	       || (h->ref_regular
> > +		   && h->root.type == bfd_link_hash_undefweak
> > +		   && (info->dynamic_undefined_weak > 0
> > +		       || !_bfd_elf_readonly_dynrelocs (h))))
> > 	      && !h->def_regular
> > 	      && !ELF_COMMON_DEF_P (h))
> > 	    {
> > 
> 
> This adds more complexity to the already complex logic "whether an undefined
> weak needs dynamic relocation when .dynsym exists".

Yes.  Unfortunately can't be avoided without affecting other targets.
(A cleaner approach is to change _bfd_elf_adjust_dynamic_symbol so
that all undefined weak symbols are seen by
elf_backend_adjust_dynamic_symbol, but doing so blows up x86_64 and
likely other targets.  I tried.)

I spent a lot of time simplifying the powerpc logic over the years so,
believe me, I don't like complicating anything here.  But contrast
this code with the mind-boggling complexity in the equivalent x86 code
still using non_got_ref, a flag that changes its meaning part way
through the link process, and using a zero_undefweak flag set per
relocation type.

> I have checked that x86-64 -no-pie a.o b.so doesn't use a dynamic
> relocation in this case. With -z dynamic-undefined-weak, there is a
> stray R_X86_64_NONE in .rela.dyn
> 
> I think a relocation type oblivious approach works equally well:

That's what I have on powerpc

> emit a dynamic relocation for -shared, suppress it for -no-pie and -pie.

but not quite like this.  -shared and -pie are treated the same.

-- 
Alan Modra
Australia Development Lab, IBM