[llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[H.J. Lu via llvm-dev]

On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song <i at maskray.me> wrote:
>
> On 2021-01-21, H.J. Lu via Gnu-gabi wrote:
> >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu <hjl.tools at 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.
> >>
> >> 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.
> >
> >--
> >H.J.
>
> Hi, H.J.
>
> Thank you for CCing llvm-dev:) In the past various GNU ABI proposals
> went unnoticed by LLVM folks who don't happen to subscribe to GNU lists.
> (A lot! I personally subscribe to some lists and check the discussion
> just in case I miss something important:) )
>
> I have researched a bit and observed that the following GNU_PROPERTY
> values are currently used by compilers/linkers:
>
> Bitwise OR for relocatable links. Bitwise AND for executable/shared
> object links.
>
> * GNU_PROPERTY_X86_FEATURE_1_AND = GNU_PROPERTY_X86_UINT32_AND_LO + 0,
> * used by Intel Indirect branch tracking and Shadow Stack
> * GNU_PROPERTY_AARCH64_FEATURE_1_AND, used by AArch64 Branch Target
> * Identification and Pointer Authentication
>
> Bitwise OR for all links.
>
> * GNU_PROPERTY_X86_ISA_1_NEEDED = GNU_PROPERTY_X86_UINT32_OR_LO + 2,
> * used by GCC -mneeded (for -march=x86-64-v[234])
>
> There appear to be another type of AND/OR bits which are not defined in
> ABIs (AFAICT):
>
> * GNU_PROPERTY_X86_ISA_1_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + 2
> * GNU_PROPERTY_X86_FEATURE_2_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO +
> * 1

I have no use for these operations for generic targets.

>
> I think generalizing the AND/OR idea to all architectures probably
> requires us to think about these questions:
>
> * What's the impending usage of the generic AND/OR ranges? ifunc? :)

I'd like to add GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION:

https://groups.google.com/g/x86-64-abi/c/DRvKxJ1AH3Q

> * Does the concept generalize well to other architectures? If we

It should work for GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION.

> * consider AArch64/x86 FEATURE_1_AND to be the same thing, the current
> * usage is purely x86 specific.
> * Is AND/OR encoding expressive enough to represent the required states?

For GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION, yes.

> * I've asked two folks and they expressed concerns. I think the three
> * AND/OR usage above speak for themselves.
> * Szabolcs Nagy mentioned that GNU_PROPERTY is an OS-specific mechanism
> * (GNU), but the features are oftentimes arch specific which make sense
> * to other OSes or bare-metal.
> * Szabolcs: Do we need any versioning mechanism?
>
> The feature selection and compatibility checking mechanism has some
> overlap with GNU/arch-specific attributes (e.g .ARM.attributes,
> .riscv.attributes).  If I understand correctly, GNU_PROPERTY has an
> associated program header so it can be checked by loaders
> (kernel/ld.so/emulator) while Attributes don't have program headers so
> they are largely assembler/linker protocols. In an inflexible way that
> such feature bits can affect observable states to loaders as well, e.g.
> .ARM.attributes can affect e_flags (soft/hard float).  .MIPS.abiflags
> has an associated program header PT_MIPS_ABIFLAGS (I know nearly nothing
> about mips) Some thoughts from mips folks would be useful.
>
> Last, I think a feature selection and compatibility checking mechanism
> is assuredly useful, but whether the current AND/OR scheme can perfectly
> satisfy that goal I am unsure. Having the proposal is a very good start,
> though:) Thanks a lot for driving the discussion:)

My current ultimate goal is GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION
with a compiler option, -fsingle-global-definition:

1. All accesses to protected definitions are local access.
2. In executable, all accesses to defined symbols are local access.
3. All global function pointers, whose function bodies aren't
locally defined, must use GOT.
4. All read/write accesses to symbols, which aren't locally defined
must, use GOT.
5. Branches to undefined symbols may use PLT.

GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION will be enforced
by assembler, linker and ld.so.

-- 
H.J.