[PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check
Tue Jun 22 13:27:42 GMT 2021
On Mon, Jun 21, 2021 at 10:46 PM Fangrui Song <email@example.com> wrote:
> On 2021-06-21, H.J. Lu wrote:
> >On Mon, Jun 21, 2021 at 9:16 PM Alan Modra <firstname.lastname@example.org> 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 <email@example.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
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
> >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:
> >> > > 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
More information about the Gcc-patches