Re: [PATCH v2] PowerPC: Initial SFrame support for 64-bit PowerPC ELF ABI
Abhay Kandpal <[email protected]>
| Newsgroups | gmane.comp.gnu.binutils |
|---|---|
| Message-ID | <[email protected]> |
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