Re: your patch enabling Arm64's GCS extension

[Srinath Parvathaneni <srinath.parvathaneni@arm.com>]

[-- Attachment #1: Type: text/plain, Size: 2065 bytes --]

Hi Jan,

On 2/12/2024 11:42 PM, Srinath Parvathaneni wrote:
> Hi Jan,
>
> On 2/12/2024 7:39 AM, Jan Beulich wrote:
>> Srinath,
>>
>> may I ask against what specification this was written? There are two
>> aspects I can't bring in line with what DDI0596 from December has, i.e.
>> even newer than the patch (dating back to October):
>>
>> 1) gcspopcx, gcspopx, and gcspushx supposedly all have an optional
>>     register operand, which gas 2.42 doesn't accept.
>
> My understanding from the following specs is that the above mentioned
>
> instructions does not take any optional arguments and this is aligned 
> with
>
> LLVM compiler behaviour.
>
> https://developer.arm.com/documentation/ddi0601/2023-12/AArch64-Instructions/GCSPUSHX--Guarded-Control-Stack-Push-exception-return-record?lang=en 
>
>
> However, I am unsure about the statement "The value in the register by 
> <Xt> is ignored" in the
>
> specs and need further clarification. I will discuss this internally 
> and get back to you with an update.

There is some confusion over the document for mentioned gcspushx, gcspopx and gcspopcx instructions.

The correct documentation for these instructions is here:
https://developer.arm.com/documentation/ddi0601/2023-12/AArch64-Instructions/GCSPOPX--Guarded-Control-Stack-Pop-exception-return-record?lang=en

As per above documentation, the mentioned instructions does not take optional argument and the current binutils implementation of these instructions is correct.

>> 2) gcsstr and gcssttr supposedly have a memory-form 2nd operand, i.e.
>>     a register name enclosed in square brackets. Gas 2.42 expects a
>>     plain register name instead.
>
> I agree this is a coding bug, I will create a bugzilla ticket and work 
> on fixing this issue.

I have committed the fix for this issue to master and binutils-2_42-branch.

Regards,

Srinath.

> Thank You.
>
> Regards,
>
> Srinath
>
>> Despite being newer it's of course possible that documentation is what
>> actually needs fixing. Can you please clarify which way it is?
>>
>> Thanks, Jan