[PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check

[H.J. Lu]

On Mon, Jun 21, 2021 at 2:32 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Mon, Jun 21, 2021 at 6:59 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > 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.
>
> How about
>
> -fprotected-abi=extern
> -fprotected-abi=extern-data
> -fprotected-abi=extern-function
> -fprotected-abi=local
> -fprotected-abi=local-data
> -fprotected-abi=local-function

-fprotected-abi=extern
-fprotected-abi=local

is simpler.

-- 
H.J.