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

Indu Bhagat <[email protected]>
Newsgroups gmane.comp.gnu.binutils
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.