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

[Abhay Kandpal]

Hi Indu,

Yes - PowerPC/SFrame support is still very much of interest, and I'd like to see it through.

On sequencing: would you prefer to complete your second-look on v2 first so I can fold any review comments into v3,
or would you rather I post a rebased v3 first? Either works for me.

Thanks,
Abhay


On 13/08/26 01:47, Indu Bhagat wrote:
> On 2026-04-29 05:55, Abhay Kandpal wrote:
>> 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
>>
>
>
> Hi Abhay,
>
> Since its been a while since you posted V2 (and I did not get time to 
> get back to your patch), Is PowerPC/SFrame support still of interest ?
>
> Thanks
> Indu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20260818/b73a619f/attachment.htm>