[PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check

[H.J. Lu]

On Mon, Jun 21, 2021 at 10:46 PM Fangrui Song <i@maskray.me> wrote:
>
> On 2021-06-21, H.J. Lu wrote:
> >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?
>
> -fno-direct-access-external-data and -fdirect-access-external-data can turn on/off the bit.
>
> clang -fno-pic -fno-direct-access-external-data  works for x86-64 and aarch64.
>
> We can add a -fno-direct-access-external

Since both clang and GCC will add a new option for both data and function
symbols, can we have an agreement on the new option name?  I am listing
options here:

1. -fdirect-access-external/-fno-direct-access-external
2. -fdirect-extern-access/-fno-direct-exern-access
3. -fdirect-external-access/-fno-direct-exernal-access
4. -fextern-access=direct/-fextern-access=indirect
5. -fexternal-access=direct/-fexternal-access=indirect

My order of preferences are 4, 5, 2, 3, 1.

> >> 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
>
> Note that this will be a glibc + GNU ld specific thing.
>
> gold and ld.lld error for copy relocations on protected data symbols by default.

At run-time, there will be a mixture of components built with different tools
over time.  A marker will help glibc to avoid potential run-time failures due
to binary incompatibility.

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



-- 
H.J.