[PATCH v2] PowerPC: Initial SFrame support for 64-bit PowerPC ELF ABI

[Abhay Kandpal]

Hi Indu,

Thanks for the review and for raising the question about motivation.

Regarding testing: yes, perf report based testing was done on both ppc64le and ppc64 (BE). On BE, missing frames were observed under perf profiling, consistent with what was seen on LE.

For the summary of why SFrame is necessary for PowerPC64, two root problems were identified:

1. Stale Link Register (LR) at NMI boundary
    When a perf NMI fires, the kernel records the current LR value. If the interrupted function has already called a sub-function, LR holds the sub-function's return address — a stale value.
    Currently, arch_skip_callchain_idx() in userspace perf reads .eh_frame to detect and prune this stale entry,
    but this is a fragile heuristic - SFrame in the kernel would allow the unwinder to resolve this directly without relying on userspace post-processing.

2. Epilogue-race / missing caller
    PPC64 epilogues restore SP with "addi r1,r1,<framesize>" before the "blr" instruction.
    If an NMI fires in this window, SP already points to the caller's frame, so the backchain walk skips the interrupted function's direct caller.
    This was reproduced on both ppc64le and ppc64 BE. No userspace heuristic can recover this lost frame — it requires kernel-side unwinding with reliable frame data, which SFrame enables.

As a supplementary finding: we also tested the signal handler context. The kernel's perf_callchain_user_64() handles signal frames correctly.
However, arch_skip_callchain_idx() was observed incorrectly pruning a valid LR entry at signal frame boundaries, causing the signal handler to go missing from call chains.
Although it can be fix seperately but this is another instance of .eh_frame-based heuristics breaking down, they do not model signal frame semantics and produce false positives at these boundaries.

Looking forward to your second-look review.

Thanks,
Abhay


On 17/04/26 01:51, Indu Bhagat wrote:
> On 3/25/26 8:04 AM, Abhay Kandpal wrote:
>> Inspired by s390 commit d27d82f560a8 ("s390: Initial support to generate
>> .sframe from CFI directives in assembler").
>>
>> Support for SFrame on PowerPC 64 is only enabled for the 64-bit PowerPC
>> ELF ABI.
>>
>> The SFrame ABI/arch identifiers SFRAME_ABI_PPC64_ENDIAN_BIG and
>> SFRAME_ABI_PPC64_ENDIAN_LITTLE are introduced for PowerPC 64 big/little
>> endian and added to the SFrame format specification.
>>
>> Port x86-64 commit d7f343eaad3f ("x86-64: Remove sframe relocs against
>> discarded sections").
>>
>> Based on s390 64-bit (s390x) commit 955570f0973d ("s390: Represent FP
>> without RA saved in SFrame").
>>
>> If an architecture uses both SFrame RA and FP tracking SFrame assumes
>> that the RA offset is the 2nd offset and the FP offset is the 3rd offset
>> following a SFrame FRE.  An architecture does not necessarily need to
>> save both on the stack (or in register) at the same time or even at all.
>> SFrame cannot represent FP without RA saved on stack (or in a register),
>> since it cannot distinguish whether the 2nd offset is the RA or FP
>> offset.
>>
>> For PPC64 use an invalid SFrame RA offset from CFA value of zero as
>> padding to represent the FP being saved when the RA is not saved.  This
>> aligns with the existing invalid SFrame fixed RA offset from CFA value
>> of zero.  In a stack tracer this then also naturally falls into place,
>> as it can skip restoring the RA in the topmost frame, if both the fixed
>> RA offset (from SFrame header) and the RA offset (from FDE) are zero,
>> without any need to test architecture-specific flags.
>>
>
> Hi Abhay,
>
> Thanks for the patch.
>
> Lets also summarise the discussion in our private thread (with you and 
> Jens) here for posterity summarising:
>   - Why is SFrame necessary for PowePC.
>
> In general, the patch looks good to me on first look. I do want to 
> test a few things, and take a second look.
>
> For the perf report based testing, was the testing done on both 
> ppc64le and ppc64 (BE) ?
>
> Thanks,
> Indu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20260429/0e5f7f87/attachment.htm>