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