Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

["Fāng-ruì Sòng" <maskray@google.com>]

On 2021-06-17, H.J. Lu wrote:
>On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>>
>> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>> >
>> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray@google.com> wrote:
>> > >
>> > > On 2021-06-17, H.J. Lu via llvm-dev wrote:
>> > > >On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>> > > >>
>> > > >> On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>> > > >> >
>> > > >> > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI
>> > > >> >
>> > > >> >  #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000
>> > > >> >  #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff
>> > > >> >
>> > > >> > A bit in the output pr_data field is set only if it is set in all
>> > > >> > relocatable input pr_data fields.  If all bits in the the output
>> > > >> > pr_data field are zero, this property should be removed from output.
>> > > >> >
>> > > >> > If the bit is 1, all input relocatables have the feature.  If the
>> > > >> > bit is 0 or the property is missing, the info is unknown.
>> > >
>> > > How to use AND in practice?
>> > > Are you going to add .note.gnu.property to all of crt1.o crti.o
>> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
>> > > files written in assembly?
>> > >
>> > > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI
>> > > >> >
>> > > >> >  #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000
>> > > >> >  #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff
>> > > >> >
>> > > >> > A bit in the output pr_data field is set if it is set in any
>> > > >> > relocatable input pr_data fields. If all bits in the the output
>> > > >> > pr_data field are zero, this property should be removed from output.
>> > > >> >
>> > > >> > If the bit is 1, some input relocatables have the feature.  If the
>> > > >> > bit is 0 or the property is missing, the info is unknown.
>> > > >> >
>> > > >> > The PDF is at
>> > > >> >
>> > > >> > https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf
>> > > >> >
>> > > >> > --
>> > > >> > H.J.
>> > > >>
>> > > >> Here is the binutils patch to implement it.
>> > > >>
>> > > >
>> > > >If there are no objections, I will check it in tomorrow.
>> > >
>> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
>> > > very kind of you if you can collect more use cases before generalizing
>> > > this into a non-arch-specific GNU PROPERTY.
>> > >
>> > > The "copy relocations on protected data symbols" thing is x86 specific
>> > > and only applies with gcc+GNU ld+glibc.
>> > > Non-x86 architectures don't have this thing.
>> > > gold doesn't have this thing.
>> > > clang doesn't have this thing.
>> >
>> > It will be used to remove copy relocation and implement canonical function
>> > pointers, which will benefit protected data and function.
>>
>> The action items in
>> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
>> can be applied without a GNU PROPERTY.
>>
>> If we want to enforce the link-time check that a shared object is no longer
>> compatible with copy relocations, just make the shared object's non-weak
>> definitions protected, and add a GNU ld diagnostic like gold
>> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
>>
>> ---
>>
>> For functions,
>>
>> On x86-64, gcc -fpic has been using  leaq    addr()(%rip), %rax since at least
>> 4.1.2 (oldest gcc I can find on godbolt):
>>
>>   __attribute__((visibility("protected")))
>>   void *addr() { return (void*)addr; }
>>
>>   // a protected non-definition declaration is the same.
>>
>>   // while asm(".protected addr") can use GOT, it is super rare if ever exists
>>   // outside glibc elf/vis*.c
>>
>> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
>> the same diagnostic:
>>
>>   relocation R_X86_64_PC32 against protected function `addr' can not
>> be used when making a shared object
>>
>> I think we can assert that taking the address of a protected function
>> never works with GNU ld.
>> So no compatibility concern.
>> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
>> doesn't need any GNU PROPERTY.
>>
>> ---
>>
>> For variables, if an object file/archive member does not have GNU PROPERTY, do
>> you consider it incompatible with "single global definition"? That is why I
>> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members
>> written in assembly.
>>
>> If you consider such an object compatible with "single global definition", I
>> don't see why a GNU PROPERTY is needed.
>>
>> If you consider such an object incompatible with "single global definition", I
>> don't see how "single global definition" benefits can be claimed giving so many
>> prebuilt object files without GNU PROPERTY.
>
>Please see the slides in
>
>https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8
>
>which includes
>
>Dynamic Linker for Single Global Definition
>• Check the single global definition marker on all components, the executable
>and its dependency shared libraries.
>• Issue an error/warning if the marker is not consistent on all components.

This is not appealing from a compatibility point of view.
It is common that a system has mixed shared objects:

-fsingle-global-definition => a.so (marker value 1)
no -fsingle-global-definition => b.so (marker value 0 or no marker)

Issuing a warning will be annoying.

If glibc x86 wants to deprecate copy relocations support,
just fix the compilers(*)/GNU ld. -fno-pic dynamically linked executables are
becoming rarer on modern Linux distributions,
When the toolchain support is sufficiently mature (e.g. ld has warned/errored),
add an opt-opt `LD_` style environment variable and let glibc ld.so warn, then gradually
make it an error.

* I can fix Clang -fno-pic at any time. I haven't done that just to be compatible with gcc -fno-pic.

>• Disallow copy relocation against definition in the shared library with the
>marker.
>• For systems without function descriptor:

>• Disallow function pointer reference in executable without the marker to the
>definition with the STV_PROTECTED visibility in a shared library with
>the marker.
>• Use the address of the function body as function pointer on functions with the
>STV_PROTECTED visibility, which are defined in shared libraries with the marker.

I have provided the solutions in my previous message.

>This provides the capability to detect the ABI change at run-time as well as
>optimize for STV_PROTECTED symbol lookup.

STV_PROTECTED symbols should not need a compiler option or a GNU PROPERTY to work (efficiently).

As my previous message mentioned (gcc 4.1.2~now; GNU ld 2.11~now),
protected function addresses in a shared object likely never work, at
least for the past 20 years.

For protected data, x86 copy relocations did not work prior to circa 2015.
It never works on non-x86, gold, clang, or non-glibc.
And I doubt any project uses protected data given that its sole purpose is for
optimization while GCC 5 added unneeded indirection.

Ulrich Drepper did add elf/vis* tests into glibc in 2000, but they use
artificial inline asm .protected which does not reflect any reality.

GNU ld -shared for a protected symbol

* x86-64: broken direct access relocation, unneeded GLOB_DAT
* aarch64: broken direct access relocation, unneeded GLOB_DAT
* arm: unneeded GLOB_DAT for STT_OBJECT
* ppc32: unneeded GLOB_DAT for STT_OBJECT
* ppc64le: good, no GLOB_DAT
* mips64el: good, no GLOB_DAT
* riscv64: good, no GLOB_DAT

Perhaps for binutils in 2000, more ports had unneeded dynamic relocations which
made the elf/vis* tests more plausible. But the fragile support (acked by
multiple glibc maintainers, including Adhemerval/Carlos/Szabolcs) is definitely
largely irrelevant nowadays.

>My linker implementation is at
>
>https://gitlab.com/x86-binutils/binutils-gdb/-/tree/users/hjl/property/master
>
>I will implement the dynamic linker change.
>
>> If we still want "absolutely no copy relocation for -fno-pic", just use GOT for
>> default visibility external data access
>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112)
>> Some architectures may not like it (i386/ppc32), just leave them behind.
>> Modern architectures can do it. When things get matured, add a ld warning,
>> then add a ld.so warning. When things get more matured, change the warnings to
>> errors.
>>
>> Such changes should use a mechanism similar to glibc LD_DYNAMIC_WEAK (weak can
>> preempt global) and Solaris LD_BREADTH (breadth-first order based dependency
>> order) and LD_NODIRECT (direct bindings). At some point, introduce a behavior
>> change.  I don't think how an explicit marker can improve the compatibility
>> story. The conceived compatibility issues likely don't really exist for
>
>The compatibility issue does exist.  Please see the linker tests I added.

ld-x86-64/protecte-func-* are artificial assembly which do not match the reality.
They are cases where never work or aren't really promised to work before.

>> functions. For copy relocations, I think we may need to wait an extended period
>> of time.
>
>That is what the single global definition marker is used for.

See my first paragraph why a GNU PROPERTY may not be a good compatibility solution.