[llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[Fangrui Song via llvm-dev]

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 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? :)
* Does the concept generalize well to other architectures? If we
* 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?
* 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:)