your patch enabling Arm64's GCS extension
Srinath Parvathaneni
srinath.parvathaneni@arm.com
Thu Feb 29 21:44:04 GMT 2024
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20240229/187ef18a/attachment.htm>
More information about the Binutils
mailing list