[PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check

[Alan Modra]

On Mon, Jun 21, 2021 at 07:12:02PM -0700, H.J. Lu wrote:
> On Mon, Jun 21, 2021 at 5:06 PM Alan Modra <amodra@gmail.com> wrote:
> >
> > On Mon, Jun 21, 2021 at 03:34:38PM -0700, Fangrui Song wrote:
> > > clang -fno-pic -fno-direct-access-extern-data  works with clang>=12.0.0 today.
> >
> > -fno-direct-access-extern-data or variations on that also seem good to
> > me.  -fpic-extern would also work.  I liked -fprotected-abi because
> > it shows the intent of correcting abi issues related to protected
> > visibility.  (Yes, it affects code for all undefined symbols because
> > the compiler clearly isn't seeing the entire program if there are
> > undefined symbols.)
> 
> I need an option which can be turned on and off.   How about
> -fextern-access=direct and -fextern-access=indirect?  It will cover
> both data and function?

Yes, FWIW that option name for gcc also looks good to me.

Now as to the need for a corresponding linker option, I'm of the
opinion that it is ideal for the linker to be able to cope without
needing special options.  Can you show me a set of object files (or
just describe them) where ld cannot deduce from relocations and
dynamic symbols what dynbss copies, plt stubs, and dynamic relocations
are needed?  I'm fairly sure I manage to do that for powerpc.

Note that I'm not against a new option to force the linker to go
against what it would do based on input object files (perhaps
reporting errors), but don't think we should have a new option without
some effort being made to see whether we really need it.

> > The main thing that struck me about -fsingle-global-definition is that
> > the option doesn't do what it says.  You can still have multiple
> > global definitions of a given symbol, one in the executable and one in
> > each of the shared libraries making up the complete program.  Which of
> > course is no different to code without -fsingle-global-definition.
> 
> 
> -- 
> H.J.

-- 
Alan Modra
Australia Development Lab, IBM