[PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check

[Alan Modra]

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.

> > 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
on powerpc that won't be useful.

-- 
Alan Modra
Australia Development Lab, IBM