Home Original page

[RFC 20/28] [SFrame-V3] gas: x86: testsuite: add new testcases for SFRAME_FDE_TYPE_FLEX_TOPMOST_FRAME

Jan Beulich jbeulich@suse.com
Thu Dec 18 09:50:08 GMT 2025 
On 18.12.2025 10:05, Jens Remus wrote:
> On 12/18/2025 9:01 AM, Jan Beulich wrote:
>> On 17.12.2025 14:04, Jens Remus wrote:
>>> On 12/17/2025 9:39 AM, Jan Beulich wrote:
>>>> On 17.12.2025 08:44, Indu Bhagat wrote:
>>>>> The items[] is created from the expression tree in cfi_escape_data data 
>>>>> for the DWARF expressions.
>>>>
>>>> While you don't even check for CFI_ESC_sleb128, I also don't see why that
>>>> would matter. CFI_ESC_* are relevant only when the expressions are actually
>>>> used for writing out to the object file. Prior to that, it's an ordinary,
>>>> plain expression supposed to evaluate to a constant (in a comment earlier
>>>> however you say you don't even need to check for it being a constant, which
>>>> feels contradictory to what you then do with the expression).
>>
>> As said here - items[], aiui, contain ordinary numbers, not ...
>>
>>>> Unless I'm overlooking a later use of the "read" variable, all you use it
>>>> for is to check the value isn't 0. Can't you have the same effect by
>>>
>>> read_sleb128_to_int64() returns number of bytes read and stores the
>>> sleb128 in a variable passed by reference.
>>>
>>>> checking items[2] itself is in range to allow it to be encoded as a single-
>>>> byte SLEB128? If the open-coding is deemed problematic, we can either add
>>>> a helper to include/leb128.h. Or wait - we already have sizeof_leb128() in
>>>> gas.
>>>
>>> Following provides a bit more context.  Patch "[RFC 20/28] [SFrame-V3] gas:
>>> x86: testsuite: add new testcases for SFRAME_FDE_TYPE_FLEX_TOPMOST_FRAME"
>>> adds a new x86-64 DRAP test:
>>>
>>> Excerpt from gas/cfi-sframe/cfi-sframe-x86_64-4.s:
>>> +       .cfi_startproc
>>> +       endbr64
>>> +       leaq    8(%rsp), %r10
>>> +       .cfi_def_cfa 10, 0
>>> +       andq    $-32, %rsp
>>> +       movq    %rdi, %rdx
>>> +       pushq   -8(%r10)
>>> +       pushq   %rbp
>>> +       movq    %rsp, %rbp
>>> +       # DW_CFA_expression, (uleb)reg, length, DW_OP_breg6, (sleb)offset
>>> +       .cfi_escape 0x10,0x6,0x2,0x76,0
>>> +       pushq   %r10
>>> +       # DW_CFA_def_cfa_expression, length, DW_OP_breg6, (sleb)offset, DW_OP_deref
>>> +       .cfi_escape 0xf,0x3,0x76,0x78,0x6
>>> ...
>>>
>>> This surfaces as follows in sframe_xlate_do_escape_cfa_expr():
>>>
>>> (gdb) p/x items
>>> $1 = {0x3, 0x76, 0x78, 0x6}
>>>
>>>   const unsigned char *buf_start = (const unsigned char *)&items[2];
>>>   const unsigned char *buf_end = buf_start + sizeof (offsetT) - 1;  
>>>   size_t read = read_sleb128_to_int64 (buf_start, buf_end, &offset);
>>>
>>> The offset (SLEB 0x78 = -8) is then stored in an SFrame FRE a few lines
>>> down:
>>
>> ... sleb128 values. 0x78 _is_ the offset; it's not an encoding of -8. Or
>> else where would that transformation to sleb128 encoding have happened?
>> And how could such even be correct (given that it may require more space
>> than is available)?
> 
> In the test case the offset was provided as raw sleb-encoded byte 0x78
> (= sleb(-8)), which I assume is one valid way of coding the expression
> using .cfi_escape:
> 
> 	# DW_CFA_def_cfa_expression, length, DW_OP_breg6, (sleb)offset, DW_OP_deref
> 	.cfi_escape 0xf,0x3,0x76,0x78,0x6

Oh, so that's where the sleb128 encoding is coming from.

> It could also have been codes as follows, which which causes an
> assertion to be triggered:
> 
> 	.cfi_escape 0xf,0x3,0x76,sleb(-8),0x6
> 
> @Indu: You should probably handle this as well.
> 
> I naively tried the following to see whether that would cause the SFrame
> code to choke as well, but it is apparently not valid assembler code, as
> it fails with assembler "Warning: zero assumed for missing expression":
> 
> 	.set DW_CFA_def_cfa_expression, 0x0f
> 	.set DW_OP_breg6, 0x76
> 	.set DW_OP_deref, 0x06
> 	.cfi_escape DW_CFA_def_cfa_expression, 3, DW_OP_breg6, sleb(-8), DW_OP_deref
> 
> Why is that so?

Because I screwed up when I added support for the sleb() etc input forms. I'll
get that fixed.

There's also a second problem here - sleb(-8) encodes to 0xf8, when it should
be 0x78.

Jan
More information about the Binutils mailing list