From: Jan Beulich <jbeulich@suse.com>
To: Indu Bhagat <indu.bhagat@oracle.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH,V4 10/14] gas: synthesize CFI for hand-written asm
Date: Thu, 11 Jan 2024 09:13:50 +0100 [thread overview]
Message-ID: <15461c7f-08eb-40a4-b24e-15df25b744e9@suse.com> (raw)
In-Reply-To: <f7c7bb8e-7034-488c-b566-0eabc10fce19@oracle.com>
On 10.01.2024 20:43, Indu Bhagat wrote:
> On 1/10/24 06:15, Jan Beulich wrote:
>> On 10.01.2024 12:26, Indu Bhagat wrote:
>>> On 1/10/24 01:44, Jan Beulich wrote:
>>>> On 10.01.2024 07:10, Indu Bhagat wrote:
>>>>> On 1/9/24 01:30, Jan Beulich wrote:
>>>>>> On 08.01.2024 20:33, Indu Bhagat wrote:
>>>>>>> On 1/5/24 05:58, Jan Beulich wrote:
>>>>>>>> On 03.01.2024 08:15, Indu Bhagat wrote:
>>>>>>>>> +/* Generate one or more generic GAS instructions, a.k.a, ginsns for the current
>>>>>>>>> + machine instruction.
>>>>>>>>> +
>>>>>>>>> + Returns the head of linked list of ginsn(s) added, if success; Returns NULL
>>>>>>>>> + if failure.
>>>>>>>>> +
>>>>>>>>> + The input ginsn_gen_mode GMODE determines the set of minimal necessary
>>>>>>>>> + ginsns necessary for correctness of any passes applicable for that mode.
>>>>>>>>> + For supporting the GINSN_GEN_SCFI generation mode, following is the list of
>>>>>>>>> + machine instructions that must be translated into the corresponding ginsns
>>>>>>>>> + to ensure correctness of SCFI:
>>>>>>>>> + - All instructions affecting the two registers that could potentially
>>>>>>>>> + be used as the base register for CFA tracking. For SCFI, the base
>>>>>>>>> + register for CFA tracking is limited to REG_SP and REG_FP only for
>>>>>>>>> + now.
>>>>>>>>> + - All change of flow instructions: conditional and unconditional branches,
>>>>>>>>> + call and return from functions.
>>>>>>>>> + - All instructions that can potentially be a register save / restore
>>>>>>>>> + operation.
>>>>>>>>
>>>>>>>> This could do with being more fine grained, as "potentially" is pretty vague,
>>>>>>>> and (as per earlier version review comments) my take on this is a much wider
>>>>>>>> set than yours.
>>>>>>>
>>>>>>> I would like to understand more on this comment, especially the "my take
>>>>>>> on this is a much wider set than yours". I see its being hinted at in
>>>>>>> different flavors in the current review.
>>>>>>>
>>>>>>> I see some issues pointed out in this review (addressing modes of mov
>>>>>>> etc, safe to skip opcodes for TEST, CMP) etc., but it seems that your
>>>>>>> concerns are wider than this.
>>>>>>
>>>>>> I earlier version review I mentioned that even vector or mask registers
>>>>>> could in principle be use to hold preserved GPR values. I seem to recall
>>>>>> that you said you wouldn't want to deal with such. Hence my use of
>>>>>> "wider set": Just to give an example, "kmovq %rbp, %k0" plus later
>>>>>> "kmovq %k0, %rbp" is a pair of "instructions that can potentially be a
>>>>>> register save / restore operation".
>>>>>>
>>>>>
>>>>> Hmm. I will need to understand them on a case to case basis. For the
>>>>> case of "kmovq %rbp, %k0" / "kmovq %k0, %rbp" how can this be used as
>>>>> save/restore to/from stack ?
>>>>
>>>> Maybe I'm still not having a clear enough picture of what forms of insns
>>>> you want to fully track. Said insn forms don't access the stack. But they
>>>> could in principle be used to preserve a certain register. Such preserving
>>>> of registers is part of what needs encoding in CFI, isn't it?
>>>>
>>>
>>> The kind of preserving is usually on stack. It can also be in another
>>> callee-saved register, in theory, but the latter defeats the purpose of
>>> state saving across calls.
>>
>> Callee-preserved registers, when they have a special purpose in the
>> architecture (like %rsi, %rdi, and %rbx have) may be cheaper to
>> preserve by moving to a call-clobbered register that isn't otherwise
>> used in the function. In the SysV ABI this only affects %rbx, the
>> special purpose of which is extremely limited in the ISA (xlatb). In
>> the Windows ABI, otoh, %rsi and %rdi are callee-preserved, and those
>> have very common uses in the string insns.
>>
>
> I am not sure I follow completely. Call-clobbered registers are not of
> interest for SCFI...
Well, what's x86_scfi_callee_saved_p() about if the distinction isn't
relevant?
>>>>>>>>> + case 0xc2:
>>>>>>>>> + case 0xc3:
>>>>>>>>> + if (i.tm.opcode_space != SPACE_BASE)
>>>>>>>>> + break;
>>>>>>>>> + /* Near ret. */
>>>>>>>>> + ginsn = ginsn_new_return (insn_end_sym, true);
>>>>>>>>> + ginsn_set_where (ginsn);
>>>>>>>>> + break;
>>>>>>>>
>>>>>>>> No tracking of the stack pointer adjustment?
>>>>>>>
>>>>>>> No stack unwind information for a function is relevant after the
>>>>>>> function has returned. So, tracking of stack pointer adjustment by
>>>>>>> return is not necessary.
>>>>>>
>>>>>> What information does the "return" insn then carry, beyond it being
>>>>>> an unconditional branch (which you have a different insn for)?
>>>>>>
>>>>>
>>>>> "return" does not carry any more information than just the
>>>>> GINSN_TYPE_RETURN as ginsn->type.
>>>>>
>>>>> So then why support both "return" and an unconditional branch: The
>>>>> intention is to carry the semantic difference between ret and
>>>>> unconditional jump. Unconditional jumps may be to a label within
>>>>> function, and in those cases, we use it for some validation and BB
>>>>> linking when creating CFG. Return, OTOH, always indicates exit from
>>>>> function.
>>>>>
>>>>> For SCFI purposes, above is the one use. Future analyses may find other
>>>>> use-cases for an explicit return ginsn. But IMO, keeping
>>>>> GINSN_TYPE_RETURN as an explicit insn makes the overall offering cleaner.
>>>>
>>>> Okay. And here you don't bother decoding operands. Hence why I'm
>>>> asking the same to be the case for (e.g.) CALL.
>>>>
>>>
>>> It seems I will need to deal with operands of RETURN insn soon. For
>>> implementing "Warn if imbalanced stack at return", we will need this info.
>>
>> Will you? Isn't stack state _before_ the RET what matters (and hence
>> the optional immediate still doesn't matter)?
>>
>
> RET with operand makes this tricky.
>
> My initial thought was:
> "Balanced stack at function return" will check that the RSP at the entry
> of the function (after the call instruction) is the same as that at the
> return from the function (before the return instruction).
>
> Now if RET with operand (which tells how much stack to pop before an
> eventual return) is in effect, I do need to check the RSP value right
> before the RETURN (RETURN being the microOP/ginsn equivalent).
No, that's not how it works. RET with operand discards arguments passed
to the function (see Windows' __stdcall calling convention for an example
use). Naturally arguments are pushed _before_ the return address.
Jan
next prev parent reply other threads:[~2024-01-11 8:13 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-03 7:15 [PATCH,V4 00/14] Synthesize " Indu Bhagat
2024-01-03 7:15 ` [PATCH,V4 01/14] gas: dw2gencfi: minor rejig for cfi_sections_set and all_cfi_sections Indu Bhagat
2024-01-03 7:15 ` [PATCH,V4 02/14] gas: dw2gencfi: use all_cfi_sections instead of cfi_sections Indu Bhagat
2024-01-03 7:15 ` [PATCH,V4 03/14] gas: dw2gencfi: expose a new cfi_set_last_fde API Indu Bhagat
2024-01-03 7:15 ` [PATCH,V4 04/14] gas: dw2gencfi: move some tc_* defines to the header file Indu Bhagat
2024-01-03 7:15 ` [PATCH,V4 05/14] gas: dw2gencfi: expose dot_cfi_sections for scfidw2gen Indu Bhagat
2024-01-03 7:15 ` [PATCH,V4 06/14] gas: dw2gencfi: externalize the all_cfi_sections Indu Bhagat
2024-01-03 7:15 ` [PATCH,V4 07/14] gas: add new command line option --scfi[=all,none] Indu Bhagat
2024-01-03 7:15 ` [PATCH,V4 08/14] gas: scfidw2gen: new functionality to prepare for SCFI Indu Bhagat
2024-01-03 7:15 ` [PATCH,V4 09/14] opcodes: i386: new marker for insns that implicitly update stack pointer Indu Bhagat
2024-01-03 7:15 ` [PATCH,V4 10/14] gas: synthesize CFI for hand-written asm Indu Bhagat
2024-01-05 13:58 ` Jan Beulich
2024-01-08 0:46 ` Indu Bhagat
2024-01-08 8:16 ` Jan Beulich
2024-01-08 8:33 ` Indu Bhagat
2024-01-08 19:33 ` Indu Bhagat
2024-01-09 9:30 ` Jan Beulich
2024-01-10 6:10 ` Indu Bhagat
2024-01-10 9:44 ` Jan Beulich
2024-01-10 11:26 ` Indu Bhagat
2024-01-10 14:15 ` Jan Beulich
2024-01-10 19:43 ` Indu Bhagat
2024-01-11 8:13 ` Jan Beulich [this message]
2024-01-11 18:14 ` Indu Bhagat
2024-01-17 1:20 ` Indu Bhagat
2024-01-17 8:09 ` Jan Beulich
2024-01-03 7:15 ` [PATCH,V4 11/14] gas: doc: update documentation for the new listing option Indu Bhagat
2024-01-03 7:15 ` [PATCH,V4 12/14] i386-reg.tbl: Add a comment to reflect dependency on ordering Indu Bhagat
2024-01-03 7:15 ` [PATCH,V4 13/14] gas: testsuite: add a x86_64 testsuite for SCFI Indu Bhagat
2024-01-05 14:22 ` Jan Beulich
2024-01-05 22:29 ` Indu Bhagat
2024-01-08 8:11 ` Jan Beulich
2024-01-03 7:15 ` [PATCH,V4 14/14] gas/NEWS: announce the new SCFI command line option Indu Bhagat
2024-01-03 7:43 ` [PATCH,V4 09/14] opcodes: i386: new marker for insns that implicitly update stack pointer Indu Bhagat
2024-01-05 14:05 ` [PATCH, V4 " Jan Beulich
2024-01-06 10:08 ` Indu Bhagat
2024-01-08 8:12 ` Jan Beulich
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=15461c7f-08eb-40a4-b24e-15df25b744e9@suse.com \
--to=jbeulich@suse.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).