[Lldb-commits] [lldb] [lldb] Improve unwinding for discontinuous functions (PR #111409)
Jason Molenda via lldb-commits
lldb-commits at lists.llvm.org
Mon Oct 7 23:13:31 PDT 2024
jasonmolenda wrote:
This is interesting, sorry the uncached unwindplans made it harder to debug.
I've seen cold function outlining in our libraries but I've never looked at the generated DWARF - does the function die have a location list with the main function body and the .cold.1 function body as entries, discontiguous? I'll try to scrub around and find one of ours and see what our DWARF looks like tomorrow on a Darwin binary that does this, curious now.
>From a symbol table point of view, if the symbol names haven't been stripped, the function symbol will have the range of the main function body only; the .cold.1 function would be a separate Symbol. In a stripped binary (no symbol name), I know ObjectFileMachO will use the eh_frame start addresses to create fake symbol table names & entries, I don't know if ObjectFileELF does that, but in that case a Symbol would be equivalent to eh_frame as a source of information.
As for why the image show-unwind is using the uncached version, it's a little hack to aid in debugging. You can turn on the verbose unwind log and do a show-unwind to see all the logging from UnwindAssemblyInstEmulation as it goes over the instructions. With the cached version, it wouldn't re-do this work so you'd miss it unless you turned on the verbose log at the beginning of the process execution (and skipped a lot of other functions that you're not interested in). You can adjust the logging level and re-do the command and it re-calculates it again, it's a bit handy like this.
I'd like to take a peek at the DWARF for a binary we have using this codegen out of curiosity, but the patch looks fine to me. It's clearly not great that this is this fragile, and I'd like to reconsider how these ranges are calculated so it's clearer what is intended. I wonder if the Dwarin debug info reflects these as separate functions, or maybe I've just gotten lucky that I never looked too closely at one.
https://github.com/llvm/llvm-project/pull/111409
More information about the lldb-commits
mailing list