[PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check

[Fangrui Song]

On 2021-06-21, H.J. Lu wrote:
>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.

Thanks... We have moved toward getting on the same page.

>> > 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.

Sorry, I made a typo. s/extern/external/

>> > 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?

The linker -Bsymbolic changes the preemptible property of a **defined**
symbol.

The compiler option is about the behavior of accessing a non-definition
declaration in C/C++.

People may be confused by different symbol sets of -fsymbolic and
-Bsymbolic. Plus, I think option names should be direct about their
affects.

If this is only one option, it can be -fno-direct-access-external,
which includes -fno-direct-access-external-{function,data}.

And I'll argue that for many architectures they should just default to
-fno-direct-access-external-function.

Whether -fno-direct-access-external-data should gradually become the
default   depends on   how much people dislike copy relocations.