Add feature name (FEAT_) support to AArch64 instructions

[AssadHashmi]

AArch64 instructions are characterised by a feature name starting with FEAT_, see:
https://developer.arm.com/downloads/-/exploration-tools/feature-names-for-a-profile

Implementations of the AArch64 architecture are more accurately described by FEAT_ feature names, than by vX.Y versions, see the explanation at #5334 (comment)

This issue will clarify how FEAT_ should be implemented. The following is proposed:

• A new enum dr_isa_feat_t similar to dr_isa_mode_t but for AArch64 only.
• API accessor functions dr_get_isa_feat() and instr_set_isa_feat().
• The AArch64 codec will specify the FEAT_ for all instructions after base v8.0.
• The system registers ID_AA64ISAR0_EL1, ID_AA64ISAR1_EL1 and ID_AA64PFR0_EL1 will be read on DynamoRIO startup in order to establish which FEAT_s are implemented by the h/w. During instruction decode and encode, the instruction's FEAT_ will be checked against the FEAT_ list implemented by the h/w, delivering an error message if the FEAT_ is not implemented.

[derekbruening]

For improved unsupported/invalid instruction support, xref #431 and #1000

For the features: today we have proc_has_feature() and the feature_bit_t enum of FEATURE_ values https://dynamorio.org/dr__proc_8h.html#a5e226019d68bd13050692da392f6c4bf. What would be the relation between that and the AArch64 features? Should the AArch64 ones be FEATURE_ instead of FEAT_ to match? Would proc_has_feature() be deprecated and dr_get_isa_feat() take its place on x86 too?

There is no x86 connection today between those features and the IR due to early decisions not to include that data in the x86 decode table, which led to the drcpusim tool on x86 using helper functions like instr_is_sse2() which has its own list of opcodes outside of the table. It might be nice to go back and add feature info into the table eventually, so ideally new interfaces we add should be able to apply to x86 without change. (It sounds like that is the case other than the relationship to the existing interface.)

[AssadHashmi]

What would be the relation between that and the AArch64 features?

Looking at the FEATURE_ enums in feature_bit_t, I don't see much semantic overlap. Only FEATURE_AES = FEAT_AES and perhaps FEATURE_RDRAND = FEAT_RNG and FEATURE_F16C = FEAT_FP16?

In terms of implementation, I think AArch64 can use the method similar to x86 but reading from system registers like ID_AA64ISAR0_EL1 rather than EBX, ECX, EDX. But there will be numerical clashes with current FEATURE_ enums. So we could either use one instance of feature_bit_t with AArch64 values offset by say 512 or have two instances of feature_bit_t. Latter seems cleaner to me.

Should the AArch64 ones be FEATURE_ instead of FEAT_ to match?

That seems fine to me. I can't imagine users complaining about the longform.

Would proc_has_feature() be deprecated and dr_get_isa_feat() take its place on x86 too?

I don't think so, now that you've made me aware of proc_has_feature() and feature_bit_t ;-)

I'll need to think about our use-cases more, but if possible we should remain consistent and use proc_get_all_feature_bits() with proc_has_feature() for AArch64 as well.