[PATCH 4/8] s390: Represent FP/RA saved in register in SFrame
Jens Remus
jremus@linux.ibm.com
Tue Apr 22 11:28:50 GMT 2025
Hello Indu,
thank you for your review feedback!
On 17.04.2025 20:50, Indu Bhagat wrote:
> On 4/2/25 9:11 AM, Jens Remus wrote:
>> GCC on s390x, when in a leaf function, can be observed to save the
>> frame pointer (FP) and/or return address (RA) register in a floating-
>> point registers (FPR) instead of on the stack. This is declared using
>> the following CFI directive:
>>
>> .cfi_register <fp/ra-regnum>, <fpr-regnum>
>>
>> SFrame cannot represent the FP and/or RA being saved in another
>> register. It does only track the CFA base register (SP/FP), CFA offset
>> from CFA base register, and FP and RA save area offsets from CFA.
>>
>> On s390x the FP and/or RA are only saved in another FPR when in a leaf
>> function. That is a function that does not call any other function.
>> Therefore it can ever only be the topmost function in a call chain.
>> An unwinder by default has access to all registers of the function that
>> is the topmost on the call stack. Therefore no further information
>> is required to restore FP/RA from the FPR.
>>
>> Represent FP/RA saved in another register on s390, by encoding the
>> DWARF register number shifted by one to the left with the least-
>> significant bit set in the offset as follows:
>>
>> offset = (regnum << 1) | 1
>>
>
> I wonder if it makes sense to just save the three bits for any future use by doing this now:
>
> offset = (regnum << 3) | 1
>
> I am still undecided.
While that would save two bits for future use as offset specific flags
it would have the downside of preventing the use of signed 8-bit SFrame
offsets in those FREs:
GCC can be observed to save the FP and RA in FPR on s390x. The lowest
FPR DWARF register number on s390x is 16 (for f0). 16 << 3 | 1 = 129.
129 does not fit into a signed 8-bit integer.
Not sure what else we might want to store in offsets. Do you see any
use for SFrame V3 support of non-SP/FP CFA base registers in the topmost
frame?
>> The use of the least-significant bit of the offset as indication is
>> possible, as the stack pointer (SP), the CFA, and any register save
>> area slots are 8-byte aligned according to the s390x ELF ABI:
>> - The stack pointer (SP) "shall maintain an 8-byte alignment". [1]
>> - The CFA is defined as SP at call site +160. [2]
>> - Pointers and 8-byte integers, such as general register values, must
>> be 8-byte aligned. [3]
>> SFrame FP and RA stack offsets must therefore always be a multiple of
>> 8 on s390x. Note that for the same reason the DWARF data alignment
>> factor is -8 on s390x (see DWARF2_CIE_DATA_ALIGNMENT).
>>
>> Add s390x-specific SFrame (error) tests for FP/RA saved in FPRs in leaf
>> function.
>>
>> [1]: s390x ELF ABI, sections "Register Roles" and "Stack Frame
>> Allocation", https://github.com/IBM/s390x-abi/releases
>> [2]: s390x ELF ABI, commit 4e38ad9c8a88 ("Document the CFA"),
>> https://github.com/IBM/s390x-abi/commit/4e38ad9c8a88
>> [3]: s390x ELF ABI, section "Fundamental Types", table "Scalar types",
>> https://github.com/IBM/s390x-abi/releases
>>
>> include/
>> * sframe.h (SFRAME_S390_OFFSET_IS_REGNUM): New S390-specific
>> macro to test whether an SFrame FP/RA offset is a DWARF register
>> number.
>> (SFRAME_S390_OFFSET_ENCODE_REGNUM): New S390-specific macro to
>> encode a DWARF register number into an SFrame FP/RA offset.
>> (SFRAME_S390_OFFSET_DECODE_REGNUM): New S390-specific macro to
>> decode an SFrame FP/RA offset into a DWARF register number.
>>
>> gas/
>> * gen-sframe.c (s390_sframe_xlate_do_register): New S390-
>> specific function. Uses SFRAME_S390_OFFSET_ENCODE_REGNUM to
>> represent FP/RA saved in another register on S390.
>> (sframe_xlate_do_register): Invoke s390_sframe_xlate_do_register
>> on S390.
>>
>> libsframe/
>> * sframe-dump.c (is_sframe_abi_arch_s390): New helper to test
>> whether ABI/arch is S390.
>> (dump_sframe_func_with_fres): Use SFRAME_S390_OFFSET_IS_REGNUM
>> and SFRAME_S390_OFFSET_DECODE_REGNUM to dump FP/RA saved in
>> another register on S390.
>> * doc/sframe-spec.texi (S390): Document S390-specific
>> representation of FP/RA saved in another register.
>>
>
> I did think for a bit: what sframe_fre_get_fp_offset () and
> sframe_fre_get_ra_offset () in libsframe/sframe.c ?
>
> On more thought, I think its okay for these APIs to return the "raw
> data", and a stack tracer for s390x can do the right thing if the LSB
> is 1 etc. However, I have not yet looked at the stacktracer fixes (in
> the branch we shared sometime ago), to be able to comment if one way
> is clunker than other. Thoughts ?
Having them return an "error" indication that the FP/RA offset is not
available, as it is actually a register number, does not seem to make
the API easier to use.
What I thought of, but assumed would require to bump to SFrame V3 API,
would be something as follows:
struct sframe_reg_save_info {
enum sframe_reg_save_loc {
REG_SAVE_NONE,
REG_SAVE_STACK,
REG_SAVE_REG,
} loc;
union {
int32_t offset;
int32_t regnum;
} u;
};
void
sframe_fre_get_fp_offset (sframe_decoder_ctx *dctx,
sframe_frame_row_entry *fre,
struct sframe_reg_save_info *fp_save_info,
int *errp);
The generic implementation (for x86-64 and AArch64) would then be:
{
int32_t offset;
offset = sframe_fre_get_fp_offset (dctx, fre, errp);
if (*errp == 0)
{
fp_save_info->loc = REG_SAVE_STACK;
fp_save_info->u.offset = offset;
}
else
fp_save_info->loc = REG_SAVE_NONE;
}
The s390x-specific implementation would then handle the case where the
offset is actually an encoded DWARF register number and return that
respectively.
As this only adds new API functions it could perhaps also be introduced
now to libsframe and used in libsframe/sframe-dump.c. What are your
thoughts?
> Perhaps we atleast add some comments, if you see appropriate, in the
> above APIs. Something along the lines that for s390x, for top most
> functions, this data may be for a save to register. The API just
> returns the raw data in the offset. Perhaps in the function-level
> comment if you like. This is just to keep things clear as sometimes
> folks may refer to libsframe APIs when implementing their own SFrame
> based stack tracer.
Sure, will add a comment.
>> diff --git a/libsframe/doc/sframe-spec.texi b/libsframe/doc/sframe-spec.texi
>> index eba497b4d371..5bd027828e3f 100644
>> --- a/libsframe/doc/sframe-spec.texi
>> +++ b/libsframe/doc/sframe-spec.texi
>> @@ -848,16 +848,27 @@ tracked in this ABI, the second stack offset is always used to locate the RA
>> stack slot, by interpreting it as: RA = CFA + offset2. The third stack offset
>> is used to locate the FP stack slot, by interpreting it as: FP = CFA + offset3.
>> -Given the nature of things, the number of stack offsets seen on S390 per
>> -SFrame FRE is either 1, 2, or 3.
>> +In leaf functions the RA and FP may be saved in other registers, such as
>> +floating-point registers (FPRs), instead of on the stack. To represent this
>> +in the SFrame stack trace format the DWARF register number is encoded as
>> +RA/FP offset using the least-significant bit (LSB) as indication:
>> +offset = (regnum << 1) | 1. A LSB of zero indicates a stack slot offset.
>> +A LSB of one indicates a DWARF register number, which is interpreted as:
>> +regnum = offset >> 1. Given the nature of leaf functions, this can only occur
>> +in the topmost frame during stack tracing.
>> +
>
> Can we also weave in something along the lines of:
>
> It is recommended that a stack tracer implementation performs the
> required sanity checks to ensure that restoring FP and RA from the
> said register locations is done only for top-most stack frames in the
> callchain.
Ok, will do.
>> +Given the nature of things, the number of stack offsets and/or register numbers
>> +seen on S390 per SFrame FRE is either 1, 2, or 3.
>> Hence, in summary:
>> -@multitable {Offset ID} {Interpretation in S390 in X}
>> +@multitable @columnfractions .15 .85
>> @headitem Offset ID @tab Interpretation in S390
>> @item 1 @tab CFA = @code{BASE_REG} + offset1
>> -@item 2 @tab RA = CFA + offset2
>> -@item 3 @tab FP = CFA + offset3
>> +@item 2 @tab RA stack slot = CFA + offset2, if (offset2 & 1 == 0)
>> + @*RA register number = offset2 >> 1, if (offset2 & 1 == 1)
>> +@item 3 @tab FP stack slot = CFA + offset3, if (offset3 & 1 == 0)
>> + @*FP register number = offset3 >> 1, if (offset3 & 1 == 1)
>> @end multitable
>> On S390, specifically s390x, the CFA is defined as stack pointer (SP) at call
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