[V3 22/36] [SFrame-V3] sframe: gas: translate specific CFI directives for SFRAME_FDE_TYPE_FLEX

[Indu Bhagat]

On 1/21/26 12:57 AM, Jan Beulich wrote:
> On 20.01.2026 22:18, Indu Bhagat wrote:
>> On 1/16/26 1:13 AM, Jan Beulich wrote:
>>> On 13.01.2026 12:12, Indu Bhagat via Binutils wrote:
>>>> @@ -1636,6 +1661,132 @@ sframe_xlate_do_gnu_window_save (struct sframe_xlate_ctx *xlate_ctx,
>>>>      return SFRAME_XLATE_ERR_NOTREPRESENTED;  /* Not represented.  */
>>>>    }
>>>>    
>>>> +/* Translate a DWARF sleb128 offset in the CFI escape data E to an int64_t.  */
>>>> +
>>>> +static offsetT
>>>> +sframe_xlate_escape_sleb128_to_int64 (const struct cfi_escape_data *e)
>>>> +{
>>>> +  offsetT offset = 0;
>>>> +
>>>> +  gas_assert (e->type == CFI_ESC_byte || e->type == CFI_ESC_sleb128);
>>>> +  /* Read the offset.  */
>>>> +  if (e->type == CFI_ESC_byte)
>>>> +    {
>>>> +      /* The user/compiler may provide an sleb128 encoded data of a single byte
>>>> +	 length (DWARF offset of DW_OP_bregN is sleb128).  On a big-endian
>>>> +	 host, the endianness of data itself needs to be accommodated then.  To
>>>> +	 keep it simple, gather the LSB, and translate it to int64.  */
>>>> +      unsigned char sleb_data = e->exp.X_add_number & 0xff;
>>>> +      const unsigned char *buf_start = (const unsigned char *)&sleb_data;
>>>> +      const unsigned char *buf_end = buf_start + 1;
>>>> +      size_t read = read_sleb128_to_int64 (buf_start, buf_end, &offset);
>>>> +      gas_assert (read);
>>>
>>> I fear asserting here isn't valid, as the user may have encoded something
>>> bogus, or (in principle) it may be a multi-byte LEB128. The latter can't
>>> occur right now as ...
>>>
>>
>> Since the code is attempting to read one byte ATM, I'd expect the assert
>> to never fail (read_sleb128_to_int64 will return 0 when start >= end).
> 
> Right, and if the byte to process (bogusly) has the top bit set, that path
> will be taken from all I can tell. Hence the assertion would trigger.
> 
>> I realize now though that this isnt necessarily fulfilling any purpose
>> other than documentation around expectations of the current code.
>>
>> I am afraid I dont understand what you are suggesting.
> 
> A diagnostic needs issuing instead. Whether that's to be an error or a
> warning I don't know.
> 

OK. I kept this as a warning, while skipping generation of SFrame FDE.

Sent a patch to ML.

Thanks