https://github.com/jasonmolenda approved this pull request.
Thanks for the background here, I can see what a problem a function with discontiguous ranges can be for some of our data structures. Looking at the assembly in your test case (which is going to be really helpful if we try to tackle this more accurately in the future), I see that the instruction scanner is also going to fail for the cold parts of the functions, which are tail-called (JMP'ed) to, if it tried to analyze the prologue setup based on the instructions in them. The eh_frame treats them as separate functions and hard-codes the correct stack setup from the base function in the cold blocks of code, that's one way to cheat this kind of thing, treating them as separate functions that have only contiguous address ranges. This looks good to me for now, we'll probably need to handle this more thoroughly in the future not only in the unwind plans. :/ https://github.com/llvm/llvm-project/pull/111409 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
