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

[Jan Beulich]

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 ...

> 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.

> 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