[RFC 21/28] [SFrame-V3] gas: sframe: add handling for .cfi_register for FP and RA
Jens Remus
jremus@linux.ibm.com
Fri Dec 19 16:10:09 GMT 2025
On 12/17/2025 2:15 PM, Jens Remus wrote:
> On 12/17/2025 9:07 AM, Indu Bhagat wrote:
>> On 12/15/25 8:19 AM, Jens Remus wrote:
>>> On 12/9/2025 10:07 AM, Indu Bhagat wrote:
>>>> Use SFrame FDE of type SFRAME_FDE_TYPE_FLEX_TOPMOST_FRAME.
>>>>
>>>> When FP, RA were moved to a general-purpose register, the SFrame
>>>> generation previously warned and skipped the FDE (except on S390X). This
>>>> patch updates the translator to detect`.cfi_register` for RA (and FP) on
>>>> AMD64, tracks the destination register in the SFrame row entry, and
>>>> emits the register in the relevant FRE offsets in SFrame FDE type
>>>> SFRAME_FDE_TYPE_FLEX_TOPMOST_FRAME.
>>> I enabled this for s390x and updated the related cfi-sframe-s390x tests,
>>> which were previously failing as SFrame V2 could not represent this.
>>> Doing so revealed that the SFrame generation logic is flawed, as it
>>> cannot differentiate between FP/RA saved on stack or in register.
>>>
>>> Attached is a quick and dirty POC, that is not polished, that works for
>>> me on s390x.
>>>
>>
>> Sorry I realized I forgot to follow up on this.
>>
>> I too, at one point, made the same change, but then rolled back thinking the
>> only thing we need to track is whether the entity is tracked or not (and
>> using SFRAME_FRE_ELEM_LOC_STACK should suffice, like it did for s390x FP/RA
>> tracking till now). I did realise the need to clean this up a bit, but I
>> thought I would take this up later, as it didnt seem like a correctness issue.
>>
>> I will take a look at your branch and get back on this.
>
> The issue is how to deduce from:
>
> .{fp|ra}_loc = { SFRAME_FRE_ELEM_LOC_REG | SFRAME_FRE_ELEM_LOC_STACK }
> .{fp|ra}_reg = <regnum>
> .{fp|ra}_offset = <offset>
>
> Whether:
> - There is no tracking info. This used to be indicated by
> .{fp|ra}_loc == SFRAME_FRE_ELEM_LOC_REG.
> - The tracking info is for FP/RA on stack. This used to be indicated
> by .{fp|ra}_loc == SFRAME_FRE_ELEM_LOC_STACK.
> - The tracking info if for FP/RA in a register. This cannot be deduced
> from anything, as 0 is both a valid register number as well as a valid
> offset.
>
> For s390x FP/RA in a register this worked, as the register number was
> encoded as offset. So it was the combination of .{fp|ra}_loc ==
> SFRAME_FRE_ELEM_LOC_STACK with an offset value that had the regnum
> indication (LSB == 1).
>
> From my point of view .{fp|ra}_loc needs to be extended to represent
> all three states:
>
> SFRAME_FRE_ELEM_LOC_{SAME|PRESERVE|RETAIN|NONE|?}: No tracking info.
> SFRAME_FRE_ELEM_LOC_STACK: Saved on stack (reg_p == 0).
> SFRAME_FRE_ELEM_LOC_REG: Saved in a register (reg_p == 1).
I have updated my personal branch a last time for this year.
The following commit implements above:
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=93d6ae285871cc929f4de67f9bc67bf775394e00
I found that the SFrame generator needs to set the deref_p bit if a
FP/RA stack offset is set. Otherwise in FLEX FDEs the stack tracer
will use the "CFA + offset" rule (= .cfi_val_offset) instead of the
"*(CFA + offset)" rule (= .cfi_offset).
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=d8cb5d8dc617052b95ce35373d8da3e6c350d8f1
diff --git a/gas/gen-sframe.c b/gas/gen-sframe.c
@@ -206,6 +206,7 @@ sframe_fre_set_ra_track (struct sframe_row_entry *fre, offsetT ra_offset)
{
fre->ra_loc = SFRAME_FRE_ELEM_LOC_STACK;
fre->ra_offset = ra_offset;
+ fre->ra_deref_p = true;
fre->ra_undefined_p = false;
fre->merge_candidate = false;
}
@@ -215,6 +216,7 @@ sframe_fre_set_fp_track (struct sframe_row_entry *fre, offsetT fp_offset)
{
fre->fp_loc = SFRAME_FRE_ELEM_LOC_STACK;
fre->fp_offset = fp_offset;
+ fre->fp_deref_p = true;
fre->merge_candidate = false;
}
I pieced together a Kernel unwind user sframe POC with SFrame V3 support
(incl. FLEX FDEs) that can finally successfully unwind my s390x test
case using my personal binutils branch with SFrame V3 fixes and s390x
support.
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
+49-7031-16-1128 Office
jremus@de.ibm.com
IBM
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
More information about the Binutils
mailing list