Re: [PATCH,V4 10/14] gas: synthesize CFI for hand-written asm

[Indu Bhagat <indu.bhagat@oracle.com>]

On 1/11/24 00:13, Jan Beulich wrote:
>>>>>>>>>> +    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.

Correct.  Even the manual clearly says "The optional source operand 
specifies the number of stack bytes to be released after the return 
address is popped; the default is none. This operand can be used to 
release parameters from the stack that were passed to the called
procedure and are no longer needed.".

So we will not need to deal with operands of RET insn.