Invalid frame addresses exist in call stack samples due to bad unwinding. This could happen to frame-pointer-based unwinding and the callee functions that do not have the frame pointer chain set up. It isn't common when the program is built with the frame pointer omission disabled, but can still happen with third-party static libs built with frame pointer omitted.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
It isn't common when the program is built with the frame pointer omission disabled, but can still happen with third-party static libs built with frame pointer omitted.
Did you mean disabled -> enabled?
This could happen to frame-pointer-based unwinding and the callee functions that do not have the frame pointer chain set up.
So this leads to frame pointer being used to volatile register and assume it contains frame pointer would lead to bad frame address when unwinding the stack during profiling, is that what you observed?
llvm/tools/llvm-profgen/PerfReader.cpp | ||
---|---|---|
524–533 | Can we hide all this complexity into getCallAddrFromFrameAddr? i.e. we could use bool getCallAddrFromFrameAddr(uint64_t FrameAddr, uint64_t &CallAddr). | |
530 | Should we be using a warning too? For truncated context due to missing probe for merged callsite, we used warning. I think this is things of similar nature, should we also handle them in similar/consistent fashion- i.e. with warning instead of stats? And if we expect duplicated warnings, would be good to deduplicated before printing. |
It's actually disabled. This happens when the program is built with -fno-omit-frame-pointer but the third-party lib is built with -fomit-frame-pointer.
This could happen to frame-pointer-based unwinding and the callee functions that do not have the frame pointer chain set up.
So this leads to frame pointer being used to volatile register and assume it contains frame pointer would lead to bad frame address when unwinding the stack during profiling, is that what you observed?
Exactly. I was seeing rbp used as a general register and its value was trashed.
llvm/tools/llvm-profgen/PerfReader.cpp | ||
---|---|---|
524–533 | Sounds good to move it into getCallAddrFromFrameAddr. | |
530 | Deduplicated warnings added. |
Should we be using a warning too? For truncated context due to missing probe for merged callsite, we used warning. I think this is things of similar nature, should we also handle them in similar/consistent fashion- i.e. with warning instead of stats?
And if we expect duplicated warnings, would be good to deduplicated before printing.