[lld] [llvm] [lld][AArch64][Build Attributes] Add support for converting AArch64 Build Attributes to GNU Properties (PR #131990)

Peter Smith via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 11 10:23:25 PDT 2025


================
@@ -207,6 +209,51 @@ static void updateSupportedARMFeatures(Ctx &ctx,
   ctx.arg.armHasThumb2ISA |= thumb && *thumb >= ARMBuildAttrs::AllowThumb32;
 }
 
+struct KnownAArch64BuildAttrSubsections {
+  struct PauthSubSection {
+    unsigned tagPlatform = 0;
+    unsigned tagSchema = 0;
+  } pauth;
+  struct FAndBSubSection {
----------------
smithp35 wrote:

I'm not sure I follow. The current tagBTI, tagPAC and tagGCS are all initialized to 0. This is functionally equivalent to a uint32_t featureAnd initialised to 0.

What I was thinking about was:
```
struct PauthSubSection {
    uint64_t tagPlatform = 0;
    uint64_t tagSchema = 0;
  } pauth;
  struct FAndBSubSection {
    uint32_t andFeatures = 0;
  } fAndB;
 ```
When we read in the BuildAttributes we just or the relevant bit.

lld also prefers to use sized types like uint32_t. If you must use individual fields from tags, then using a potentially 64-bit size type for a feature bit is wasteful. You can use a bitfield for example. This observation is what lead me to propose using just featureAnd as that is pretty much identical to a uint32_t bitfield, but maybe a bit more portable and it can be compared with the existing andFeatures more easily.

Yes there are only 3 feature bits defined now, but there could be up to 32, so that FAndBSubSection could get big, both at runtime, and in the number of lines in the source code.

This is just my opinion, will have to see if there is a consensus among other reviewers.

https://github.com/llvm/llvm-project/pull/131990


More information about the llvm-commits mailing list