From: Richard Sandiford <richard.sandiford@arm.com>
To: Indu Bhagat <indu.bhagat@oracle.com>
Cc: binutils@sourceware.org, Richard.Earnshaw@arm.com
Subject: Re: [PATCH,V4 7/8] gas: aarch64: add experimental support for SCFI
Date: Thu, 11 Jul 2024 21:10:21 +0100 [thread overview]
Message-ID: <mptplrjpu4y.fsf@arm.com> (raw)
In-Reply-To: <8bc9fd54-bceb-4440-84d4-46afa8de8119@oracle.com> (Indu Bhagat's message of "Thu, 11 Jul 2024 12:07:40 -0700")
Indu Bhagat <indu.bhagat@oracle.com> writes:
> On 7/11/24 06:15, Richard Sandiford wrote:
>> Indu Bhagat <indu.bhagat@oracle.com> writes:
>>> On 7/1/24 12:49, Richard Sandiford wrote:
>>>> Indu Bhagat <indu.bhagat@oracle.com> writes:
>>>>> +{
>>>>> + enum aarch64_operand_class opnd_class;
>>>>> + unsigned int dw2reg_num = 0;
>>>>> +
>>>>> + opnd_class = aarch64_get_operand_class (opnd->type);
>>>>> +
>>>>> + switch (opnd_class)
>>>>> + {
>>>>> + case AARCH64_OPND_CLASS_FP_REG:
>>>>> + dw2reg_num = opnd->reg.regno + 64;
>>>>> + break;
>>>>> + case AARCH64_OPND_CLASS_SVE_REGLIST:
>>>>> + dw2reg_num = opnd->reglist.first_regno + 64;
>>>>> + break;
>>>>> + case AARCH64_OPND_CLASS_MODIFIED_REG:
>>>>> + case AARCH64_OPND_CLASS_INT_REG:
>>>>> + case AARCH64_OPND_CLASS_ADDRESS:
>>>>> + /* Use a dummy register value in case of WZR, else this will be an
>>>>> + incorrect dependency on REG_SP. */
>>>>> + if (!sp_allowed_p && opnd->reg.regno == REG_SP)
>>>>> + dw2reg_num = GINSN_DW2_REGNUM_R1_DUMMY;
>>>>> + else
>>>>> + /* For GPRs of our interest (callee-saved regs, SP, FP, LR),
>>>>> + DWARF register number is the same as AArch64 register number. */
>>>>> + dw2reg_num = opnd->reg.regno;
>>>>> + break;
>>>>
>>>> I think the AARCH64_OPND_CLASS_ADDRESS case should look at opnd->addr
>>>> instead. AARCH64_OPND_CLASS_MODIFIED_REG should look at opnd->shifter.
>>>>
>>>
>>> Made the correction for AARCH64_OPND_CLASS_ADDRESS.
>>>
>>> But for AARCH64_OPND_CLASS_MODIFIED_REG, the register information is
>>> still correct in opnd->reg.regno, IIUC. It seems to me that the only
>>> information available in the opnd->shifter is how the register is
>>> modified by additional work (shift, multiply etc.); This information is
>>> not used by SCFI:
>>> - an add/sub with two source register and destination REG_SP/ REG_FP
>>> makes REG_SP/ REG_FP untraceable. So ignoring the shift amount etc does
>>> not hurt SCFI correctness.
>>> - Cant think of other operations where the shift amount will affect
>>> SCFI correctness..
>>>
>>> So I am not sure of the "AARCH64_OPND_CLASS_MODIFIED_REG should look at
>>> opnd->shifter." of the review comment.
>>
>> It's more about type correctness. "shifter" is the data associated with
>> AARCH64_OPND_CLASS_MODIFIED_REG and "reg" is the data associated with
>> AARCH64_OPND_CLASS_INT_REG etc. I think it's mostly a coincidence
>> that the "reg" and "shifter" alternatives of the union put the register
>> at the same byte offset from the start of the structure.
>>
>
> The shifter struct is out of the union in struct aarch64_opnd_info.
Oops, yes, I shouldn't have relied on memory. Sorry for the noise.
Richard
next prev parent reply other threads:[~2024-07-11 20:10 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 2:53 [PATCH,V4 0/8] Add SCFI support for aarch64 Indu Bhagat
2024-07-01 2:53 ` [PATCH,V4 1/8] gas: scfi: make scfi_state_restore_reg function more precise Indu Bhagat
2024-07-12 15:03 ` [PATCH, V4 " Indu Bhagat
2024-07-01 2:53 ` [PATCH,V4 2/8] include: opcodes: aarch64: define new subclasses Indu Bhagat
2024-07-01 17:40 ` Richard Sandiford
2024-07-11 5:14 ` Indu Bhagat
2024-07-11 12:22 ` Richard Sandiford
2024-07-11 17:59 ` Indu Bhagat
2024-07-01 2:53 ` [PATCH,V4 3/8] opcodes: aarch64: flags to denote subclasses of ldst insns Indu Bhagat
2024-07-01 18:06 ` Richard Sandiford
2024-07-11 5:45 ` Indu Bhagat
2024-07-12 13:59 ` Indu Bhagat
2024-07-13 7:34 ` Indu Bhagat
2024-07-01 2:54 ` [PATCH,V4 4/8] opcodes: aarch64: flags to denote subclasses of arithmetic insns Indu Bhagat
2024-07-01 18:13 ` Richard Sandiford
2024-07-11 5:47 ` Indu Bhagat
2024-07-11 12:52 ` Richard Sandiford
2024-07-11 17:58 ` Indu Bhagat
2024-07-11 18:43 ` Richard Sandiford
2024-07-12 12:53 ` Indu Bhagat
2024-07-01 2:54 ` [PATCH,V4 5/8] opcodes: aarch64: flags to denote subclasses of uncond branches Indu Bhagat
2024-07-01 2:54 ` [PATCH,V4 6/8] opcodes: aarch64: enforce checks on subclass flags in aarch64-gen.c Indu Bhagat
2024-07-01 2:54 ` [PATCH,V4 7/8] gas: aarch64: add experimental support for SCFI Indu Bhagat
2024-07-01 19:49 ` Richard Sandiford
2024-07-11 6:30 ` Indu Bhagat
2024-07-11 13:15 ` Richard Sandiford
2024-07-11 19:07 ` Indu Bhagat
2024-07-11 20:10 ` Richard Sandiford [this message]
2024-07-01 2:54 ` [PATCH,V4 8/8] gas: aarch64: testsuite: add new tests " Indu Bhagat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mptplrjpu4y.fsf@arm.com \
--to=richard.sandiford@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=binutils@sourceware.org \
--cc=indu.bhagat@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).