[PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check

[H.J. Lu]

On Mon, Jun 21, 2021 at 6:50 AM Alan Modra <amodra@gmail.com> wrote:
>
> On Mon, Jun 21, 2021 at 05:42:06AM -0700, H.J. Lu wrote:
> > On Mon, Jun 21, 2021 at 3:46 AM Alan Modra <amodra@gmail.com> wrote:
> > >
> > > I'm happy with the direction of this patch series, but do consult with
> > > ARM maintainers before committing.
> >
> > Nick, Richard, what do you think?
> >
> > > On Sun, Jun 20, 2021 at 03:50:29PM -0700, H.J. Lu via Binutils wrote:
> > > > If GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION is set on any input
> > > > relocatable files:
> > > >
> > > > 1. Don't generate copy relocations.
> > > > 2. Turn off extern_protected_data.
> > > > 3. Treate reference to protected symbols with single global definition
> > > > as local.
> > > > 4. Set GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION on output.
> > > > 5. Add -z [no]single-global-definition to control single global definition.
> > >
> > > This doesn't seem a good name.  I think the name should have
> > > "protected" in it somewhere, since what you are doing here affects the
> > > way the x86 and arm toolchains treat protected visibility symbols.
> >
> > Removing copy relocation and canonical function pointers do help
> > protected symbols in shared libraries.
>
> Right.
>
> >  But their impacts on executable
> > are unrelated to protected symbols.
>
> Obviously you do need some option to control code generated by gcc
> (and the gcc option name also doesn't seem right to me).  I understand
> what you're trying to say in the name but it won't convey much to
> users.
>
> >  Do you have any suggestions?
>
> Perhaps -fprotected-abi=nocopy and -fprotected-abi=copy for the gcc
> options?  Or just -fprotected-abi and -fprotected-abi=copy.  Saying
> with the first that code is respecting the ELF gABI, while with the
> second you're being tricky with dynbss copies and copy relocations.

This also impacts function pointers.  "copy" doesn't cover it.   Florian
also points out that we need a different behavior in executable.   Since
linker has all information, it may be able to set/clear the bit properly
based on input relocations.

> > > Hmm, do you even need a new linker option?  Powerpc toolchains behave
> > > as you are proposing for x86, without needing special linker options.
> > >
> >
> > I added these linker options to use them in glibc tests:
>
> But you are trying to drive the linker via notes too, so why is it
> necessary to also have a linker command line option?
>
> > https://sourceware.org/pipermail/libc-alpha/2021-June/127770.html
> >
> > If the linker options are x86 specific, these tests will only run on
> > x86 targets.
>
> I think that indeed any new linker option should be treated just like
> -z noextern-protected-data and be enabled using another file like
> emulparams/extern_protected_data.sh.  I don't want a -z linker option

I will make the change.

> on powerpc that won't be useful.

Thanks.

-- 
H.J.