[PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check

[H.J. Lu]

On Mon, Jun 21, 2021 at 3:49 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Mon, Jun 21, 2021 at 3:34 PM Fangrui Song <i@maskray.me> wrote:
> >
> > On 2021-06-21, H.J. Lu via Binutils 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
> >
> > I don't think the option name needs to mention "protected".
> >
> > First, -fpie and -fpic use GOT for external data/function today, no need
> > for a new option.
> >
> > The option is used with -fno-pic to prevent interaction issues with
> > protected definitions in shared objects, but the option itself doesn't
> > do anything with protected. For instance, the option can fix the pointer
> > equality issue with a -Bsymbolic or --dynamic-list linked shared object as well.
> > So I don't think the option name needs to mention "protected".
>
> It sounds reasonable.
>
> > clang -fno-pic -fno-direct-access-extern-data  works with clang>=12.0.0 today.
> > The GCC feature request is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112.
> >
> > When taking an external function address in -fno-pic code, I suggest
> > -fno-direct-access-extern-function
> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593). Actually, for
> > many arches I suggest that we just use GOT by default, no need for a
> > toggle.
> >
> > For x86-64 -fpie, we should just apply
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html
> >
>
> I'd like to have a single option to use GOT to access external symbols
> and make protected symbols local.   Programmer doesn't have to know
> if PIE is enabled by default nor if copy relocation is used by default.
>
> -fsingle-global-definition isn't a good name.  But I can't find a better one.
>

How about -fsymbolic, similar to linker -Bsymbolic?

-- 
H.J.