[PATCH v1] aarch64: Remove guarding restrictions on system registers by default.

[Srinath Parvathaneni]

Hi,

On 6/11/25 10:44, Jan Beulich wrote:
> On 11.06.2025 11:28, Srinath Parvathaneni wrote:
>>
>> The current implementation of system register in assembler are
>> guarded by following rules:
>> 1. No restrictions.
>> 2. Architecture version (eg: armv8.5-a)
>> 3. Architecture features (eg:+sve)
>> 4. Combination of both architecture version and architecture
>>     feature (eg: armv9.5-a+profile).
>> 5. Combination of multiple architecture features (eg: +memtag+pops).
>>
>> In this patch we are removing all the above mentioned guarding
>> restrictions and making the system registers available by default
>> in the assembler.
> 
> You say what you do, but not why. That's a relevant part towards accepting
> (or rejecting) such a change, though. Plus ...
>

I'm making this changes so that GNU assembler aligns with LLVM in which 
the system registers are available by default without any guarding.


>> Also we are adding a command line flag "-menable-sysreg-checking",
>> which enforces the current restrictions on system registers.
> 
> ... from that I conclude you don't really remove the restrictions (from
> the sources), but merely don't enforce them.
> 

Yes, you are right. I should correct my wording here. In this patch we 
are not removing the guarding restrictions on system registers but we 
are disabling those checks and they are enforced by passing mentioned
command line option.

I will later edit the commit message accordingly.

>> But there is one exception with the default behaviour, even though we
>> have removed all the restrictions on system registers, the 128 bit
>> system instructions like mrrs and msrr which uses the 128 bit system
>> registers as operands, are not available unless we pass
>> ".arch_extension d128" directive or "+d128" flag to the assembler.
>>
>> eg:
>> 	.arch_extension d128 // For the msrr and mrrs instructions.
>>          msrr    rcwmask_el1, x2, x3
>>          mrrs    x2, x3, rcwmask_el1
>>
>> All the current system registers *.d files are added with
>> "-menable-sysreg-checking" flag to assembler, so that all those
>> system registers get testing with current guarding restrictions.
>>
>> Also we have tested the assembler behaviour with this patch for
>> following scenarios:
>> 1. sysregs with no guarding reatrictions.
>> 2. sysregs with no guarding restrictions + "-menable-sysreg-checking".
>> 3. sysregs with guarding restrictions + "-menable-sysreg-checking".
>>
>> Regression tested for aarch64-none-elf target and found no regressions.
> 
> Exporting a variable from a shared library is, imo, not very nice.
> As an aside, the variable would also better be of type bool. Just
> that struct aarch64_option_table's respective field type doesn't
> allow for that (which hence imposes a restriction on libopcode
> despite being gas-internal).
> 
> Jan

I agree it is not ideal to exporting variable from a shared library, but 
the code related to system register checking is spread across multiple 
files and I don't see an alternative.

Also use of bool seems more appropriate but aarch64_option_table doesn't 
allow this as you have already mentioned. I tried modifying the "struct 
aarch64_option_table" but that results in lot of unnecessary code 
changes and also some code changes in common files.

I'm open to any suggestions, if there are any alternative ways to 
approach this, please let me know.

Regards,
Srinath.