[PATCH,V2 4/4] gas: sframe: handle .cfi_same_value
Jens Remus
jremus@linux.ibm.com
Mon May 19 08:10:25 GMT 2025
Hello Jan!
On 18.05.2025 10:13, Jan Beulich wrote:
> On 16.05.2025 18:02, Jens Remus wrote:
>> On 15.05.2025 23:06, Indu Bhagat wrote:
>>> Fix PR gas/32953 - sframe: incorrect handling of .cfi_same_value in gas
>>>
>>> As per documentation, .cfi_same_value indicates that the current value
>>> of register is the same like in the previous frame, i.e. no restoration
>>> needed.
>>>
>>> In some cases, SFrame has no means to encode this information. Warn and
>>> skip generating the SFrame FDE in those cases.
>>
>>> diff --git a/gas/gen-sframe.c b/gas/gen-sframe.c
>>
>>> + SFrame based stacktracers will implement CFA-based SP recovery for all ABIs:
>>> + SP for previous frame is based on the applicable CFA-rule. There is no
>>> + representation in SFrame to indicate "no restoration needed" for REG_SP. So
>>> + skip generating the SFrame FDE if DW_CFA_same_value is seen for
>>> + SFRAME_CFA_SP_REG.
>>
>> I think SFrame should treat .cfi_same_value <SP> the same way as
>> .cfi_restore <SP>. That is ignore, as a SFrame based stack tracer will
>> restore SP using the implicit CFA-rule anyway. At least SFrame should
>> treat both in the same way (either ignore or skip emitting the FDE).
>>
>> This is different from .cfi_same_value <RA>, which resets any previous rule
>> for RA, as for SP there is always the implicit rule.
>>
>> Another argument to ignore is that SFrame does also ignore
>> .cfi_offset <SP>, <offset>, which would define a rule for SP that SFrame
>> cannot represent. But given the implicit CFA-rule it can safely ignore it.
>
> Can it? Isn't an explicit directive always overriding any implicit rules?
SFrame currently only tracks the CFA base register (only FP or SP),
CFA offset from CFA base register, and the FP and RA stack slot offsets
from CFA. For the SP it always uses an implicitly assumed SP value
offset from CFA rule. For all architectures, except S390, which follow
the DWARF suggestion to define CFA as SP at call site: SP = CFA. For
S390, given the CFA is defined as SP at call site + 160: CFA = SP - 160.
DWARF mandates the value of the CFA to be constant throughout a function:
"The algorithm to compute CFA changes as you progress through the
prologue and epilogue code. (By definition, the CFA value does not
change.)"
Unless an architecture violates DWARF, the implicitly assumed SP value
offset form CFA rule should always be valid.
At least for S390 SFrame needs to ignore any explicit SP rules, as the
SP is usually saved in the prologue of non-leaf functions accompanied
by a respective .cfi_offset rule. This has no effect on the validity of
the implicit SP value offset from CFA rule.
Note that there exist cases where the CFA value being constant throughout
a function is violated, such as implementations of Glibc longjmp, where
some architectures re-define the CFA to point at the jump buffer to
implement the following Glibc requiement (from Glibc manual/probes.texi):
"The @code{longjmp} probe is triggered at a point where the registers
have not yet been restored to the values in the @code{jmp_buf} and
unwinding will show a call stack including the caller of
@code{longjmp} or @code{siglongjmp}.
...
The @code{longjmp_target} probe is triggered at a point where the
registers have been restored to the values in the @code{jmp_buf} and
unwinding will show a call stack including the caller of @code{setjmp}
or @code{sigsetjmp}."
At least I understand x86-64 does so in Glibc sysdeps/x86_64/__longjmp.S:
LIBC_PROBE (longjmp, 3, LP_SIZE@%RDI_LP, -4@%esi, LP_SIZE@%RDX_LP)
/* We add unwind information for the target here. */
cfi_def_cfa(%rdi, 0) <-- CFA now points at jump buffer
...
cfi_offset(%rbx,JB_RBX*8)
cfi_offset(%r12,JB_R12*8)
cfi_offset(%r13,JB_R13*8)
cfi_offset(%r14,JB_R14*8)
cfi_offset(%r15,JB_R15*8)
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