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

[Jan Beulich]

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.

Jan