Issue |
137385
|
Summary |
[lldb] Using `.debug_frame` unwind info for IPs without symbol/function info
|
Labels |
new issue
|
Assignees |
|
Reporter |
SingleAccretion
|
The mechanical reproduction for this issue as I encountered is somewhat complex, here are the ingredients:
1) Windows host, or otherwise ensuring that the "default" unwind plan is wrong for `FW` below.
2) Stepping into a function _without_ debug info (`FN`) from a function _with_ debug info (`FW`). The debug info format is DWARF.
3) Both functions have correct unwinding information recorded in `.debug_frame`, but there is no `.eh_frame`.
Under these very specific conditions, step-in behavior will be wrong (we expect a graceful step-over), with "how wrong" depending on how wrong the default unwind plan is for `FN` calling `FW`. In my case (wasmtime-transformed DWARF, `FN` is a WASM function with WASM-level DWARF, `FW` - without), the step-over resulted in returning to the caller of `FN`, due to the CFI essentially being computed for `FN` instead of `FW`.
It is easier to explain the problem with looking through the code responsible for finding the unwind plan in this case. First, we get into `InitializeZerothFrame` and fail to get a symbol context:
https://github.com/llvm/llvm-project/blob/0383e545d1f6a5ccd1fc8177c9a9e52f5809c4f3/lldb/source/Target/RegisterContextUnwind.cpp#L163-L176
Then we get into `GetFullUnwindPlanForFrame`:
https://github.com/llvm/llvm-project/blob/0383e545d1f6a5ccd1fc8177c9a9e52f5809c4f3/lldb/source/Target/RegisterContextUnwind.cpp#L850-L878
Here, since `m_sym_ctx_valid == false`, we don't get to `GetFuncUnwindersContainingAddress`, which would find our PC in the `.debug_frame` table, and there is no `.eh_frame`, so we return the default unwind plan.
Looking a bit more at the code, it seems it would be possible to remove the `m_sym_ctx_valid` check, and always ask `GetFuncUnwindersContainingAddress` for the unwind plan, since its callees can handle a missing symbol context (by getting the code range from the unwinding sections).
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs