[V2 18/36] [SFrame-V3] gas: sframe: output new FDE type SFRAME_FDE_TYPE_FLEX
Jens Remus
jremus@linux.ibm.com
Mon Jan 12 10:28:58 GMT 2026
Hello Indu, Jose, Steven, et al.,
On 1/7/2026 9:42 AM, Indu Bhagat wrote:
> This patch updates the routines for emission of the new FDE type
> SFRAME_FDE_TYPE_FLEX in the SFrame output section. The support for
> generating these flex FDEs themselves is added in a subsequent commit.
>
> For flex FDE type, output_sframe_row_entry_offsets () emits two
> offsets for RA tracking, irrespective of the ABI/arch, i.e.,
> irrespecitve of whether RA-tracking is enabled. This is because, for
Please mention that only a single FP/RA padding "offset" is used when
FP location info without RA location info is encoded.
> flex FDE type, RA is allowed "non-standard" recovery rules,
> e.g., RA = REG or RA = *(REG+offset). In a follow-up patch, when
> handling for .cfi_register RA, REG is added, emission code will be
> patched up accodingly.
TL;DR: Recap of why a single padding offset of zero is acceptable.
Skip to stack tracer implications below.
Regarding whether a single RA padding offset of zero (instead of two) is
sufficient to represent FP without RA saved:
reg_data = SFRAME_V3_FLEX_FDE_REG_ENCODE (0 /* regnum */, 0 /* deref_p */, 0 /* reg_p */)
= SFRAME_FRE_RA_OFFSET_INVALID
= 0
We established that this encoding rules out to represent the CFI
directive .cfi_val_offset RA, <offset> (means RA = CFA + <offset>) in
SFrame V3 without any additional flag in reg_data.
This would not be an issue for RA, as .cfi_val_offset specifies an
address on the stack (as long as CFA points somewhere to the stack),
which should never be valid for the return address.
For FP this should not be useful either, as the FP value at entry
should not be known and thus not be representable related to CFA.
For SP, if SFrame would ever be extended to track SP, the only
sensible rule should be the one from the CFA definition
(e.g. CFA = SP at call site or CFA = SP at call site + 160 on s390x),
which would not need to be explicitly encoded, as it is already
implicitly assumed to unwind SP.
If the need to represent .cfi_val_offset {SP|FP|RA} would still arise,
the spare unused bit in reg_data could possibly be used. It may be
required after all, as .cfi_val_offset {SP|FP|RA}, <offset> encodes as:
reg_data = 0;
offset_data = <offset>;
An offset value of zero (on architectures such as s390x that do not use
zero as default), would need explicit indication in reg_data to be
differentiated from two padding offsets of zero.
Stack tracer implications of using single padding offsets in flexible
SFrame FDEs (at the example of WIP Linux Kernel unwind user sframe):
TL;DR: Disallowing trailing padding offsets would slightly simplify the
flex FDE FRE offset decoding logic, as it allows to test for
(offset_count >= 2) once instead of (offset_count > 0) twice.
A) Flex FDE FRE offset decoding logic when using two padding offsets:
/* offset_count >= 2, as it is neither zero nor odd */
UNSAFE_GET_USER_INC(cfa_reg, cur, offset_size, Efault);
UNSAFE_GET_USER_INC(cfa_off, cur, offset_size, Efault);
offset_count -= 2;
cfa_off = sframe_cfa_offset_decode(cfa_off);
ra_off = sec->fp_off;
ra_reg = ra_off ? 2 : 0; /* deref_p=(ra_off != 0) */
if (offset_count >= 2) {
UNSAFE_GET_USER_INC(ra_reg, cur, offset_size, Efault); <-- unconditionally read two offsets
UNSAFE_GET_USER_INC(ra_off, cur, offset_size, Efault);
offset_count -= 2;
if (!ra_reg && !ra_off) {
/* Padding RA location info */
ra_off = sec->ra_off;
if (ra_off)
ra_reg = 2; /* deref_p=(ra_off != 0) */
}
}
[... likewise for FP ...]
if (offset_count)
return -EFAULT;
B) Flex FDE FRE offset decoding logic when using single padding offset
and disallowing trailing padding offsets:
if (offset_count < 2)
return -EFAULT;
UNSAFE_GET_USER_INC(cfa_reg, cur, offset_size, Efault);
UNSAFE_GET_USER_INC(cfa_off, cur, offset_size, Efault);
offset_count -= 2;
cfa_off = sframe_cfa_offset_decode(cfa_off);
ra_off = sec->fp_off;
ra_reg = ra_off ? 2 : 0; /* deref_p=(ra_off != 0) */
if (offset_count >= 2) { <-- either [ra_reg_data, ra_offset] or [SFRAME_FRE_RA_OFFSET_INVALID, fp_reg_data]
UNSAFE_GET_USER_INC(ra_reg, cur, offset_size, Efault);
offset_count--;
if (ra_reg) {
UNSAFE_GET_USER_INC(ra_off, cur, offset_size, Efault);
offset_count--;
} else {
/* Padding RA location info */
ra_off = sec->ra_off;
if (ra_off)
ra_reg = 2; /* deref_p=(ra_off != 0) */
}
}
[... likewise for FP ...]
if (offset_count)
return -EFAULT;
C) Flex FDE FRE offset decoding logic when using single padding offset
but allowing trailing padding offsets:
if (offset_count < 2)
return -EFAULT;
UNSAFE_GET_USER_INC(cfa_reg, cur, offset_size, Efault);
UNSAFE_GET_USER_INC(cfa_off, cur, offset_size, Efault);
offset_count -= 2;
cfa_off = sframe_cfa_offset_decode(cfa_off);
ra_off = sec->fp_off;
ra_reg = ra_off ? 2 : 0; /* deref_p=(ra_off != 0) */
if (offset_count) {
UNSAFE_GET_USER_INC(ra_reg, cur, offset_size, Efault);
offset_count--;
if (ra_reg) {
if (!offset_count) <-- additional test required
return -EFAULT;
UNSAFE_GET_USER_INC(ra_off, cur, offset_size, Efault);
offset_count--;
} else {
/* Padding RA location info */
ra_off = sec->ra_off;
if (ra_off)
ra_reg = 2; /* deref_p=(ra_off != 0) */
}
}
[... likewise for FP ...]
if (offset_count) <-- TODO: test for additional padding offsets?
return -EFAULT;
What are your thoughts regarding the single padding offsets and whether
to allow for trailing padding offsets? Why would they be useful?
If I find some time besides getting the Kernel unwind user sframe
series into shape for review, I plan to do some SFrame size comparison
on s390x of the following:
SFrame V2
SFrame V3, flex FDE disabled, use SFrame V2 register as offset encoding
SFrame V3, flex FDE disabled, use SFrame V3 register as offset encoding
SFrame V3, flex FDE enabled only for .cfi_register
SFrame V3, flex FDE fully enabled (this patch series)
Thanks and regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
More information about the Binutils
mailing list