[PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check

H.J. Lu hjl.tools@gmail.com
Tue Jun 22 04:42:26 GMT 2021


On Mon, Jun 21, 2021 at 9:16 PM Alan Modra <amodra@gmail.com> wrote:
>
> 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.

I will change the gcc option to

-fextern-access=direct
-fextern-access=indirect

and change GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION
to GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS

> 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

I'd like to turn it on in linker without any compiler changes, especially
when building shared libraries, kind of a subset of -Bsymbolic.

> reporting errors), but don't think we should have a new option without
> some effort being made to see whether we really need it.

Here is a glibc patch to use both linker options on some testcases:

https://sourceware.org/pipermail/libc-alpha/2021-June/127770.html

> > > 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



-- 
H.J.


More information about the Binutils mailing list