[PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check

[H.J. Lu]

On Tue, Jun 22, 2021 at 6:33 AM Michael Matz <matz@suse.de> wrote:
>
> Hello,
>
> On Mon, 21 Jun 2021, H.J. Lu via Binutils wrote:
>
> > > 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
>
> But Alan asked for examples where the linker option is absolutely
> required.  AFAICS in the above examples the linker can determine the
> situation from the input files because (if either the right compiler
> options are used, or because that's the default for the architecture)
> they will contain only GOT relocations to the undefined symbols, and hence
> no copy relocs are needed or emitted.

For new compilers, "-z single-global-definition" isn't needed.  But it can
be used with the old compilers to enable linker optimization.

> Simply look at the busy work that you need to go through in one part of
> above patch:
>
> +ifeq ($(have-fsingle-global-definition),yes)
> +# Compile tst-prelink.c with -fno-single-global-definition to keepp COPY
> +# relocation.
> +CFLAGS-tst-prelink.c += -fno-single-global-definition
> +endif
> +ifeq ($(have-z-single-global-definition),yes)
> +# Link tst-prelink with -z nosingle-global-definition to keepp COPY
> +# relocation.
> +LDFLAGS-tst-prelink += -Wl,-z,nosingle-global-definition
> +endif
>
> So, the only purpose of the linker flag seems to be to reflect what the
> compiler was already knowing, that it emitted a PC-relative reloc that
> ultimately requires a copy reloc.  The linker readily sees this, there's
> no need for an option, or is there?

For old compilers, "-z no-single-global-definition" isn't needed.   Linker
works better when it knows if copy relocation should be avoided at the
very beginning.   The property marker provides such info to linker.
"-z no-single-global-definition" tells linker to ignore such marker to
keep copy relocation.  For this particular testcase, the program runs
normally without copy relocation.  But the prelink test only works with
copy relocation.   We can either skip this test with the new tools or
keep copy relocation with the new tools using a linker option.  Since
I'd like to keep the test with the new tools, I use a linker option.

-- 
H.J.