jasonmolenda added a comment. Hi Pavel, sorry I've been doing a bunch of random things today and haven't really had a chance to look at this yet. eh_frame is so problematic for lldb, we never know what we're getting. I keep thinking we should take over a few augmentation string characters so that the producer can definitively indicate one of:
Synchronous unwind only - at throwable locations, or when unwinding up the stack for a throw. Fully describes prologue setup. Fully describes epilogue(s) teardown. Fully asynchronous - unwind information is correct at all instructions. When we set up a stack frame (and base things off of the frame pointer), that can cover up a multitude of eh_frame issues as long as we get the prologue/epilogue. All the bugs tend to come out when we start using -fomit-frame-pointer, or look at leaf frames. ;) I don't know if gcc still does this, but I remember ages ago if you had i386 32-bit PIC code and needed to refer to pc-relative data it would do a CALLQ next-instruction and then pop the saved pc off the stack, without any unwind information at that point. Maybe it does that now. With x86_64, I know gcc emits prologue & epilogue, and clang probably does too now (we rarely use eh_frame on macOS systems so it's been a while since I've seen it). I don't know what icc does. Given how rarely people bother with omit-frame-pointer codegen on x86_64 (it was more important on 32-bit i386), and prologue+epilogue were often present, I was fine with living on eh_frame as the primary unwind mechanism. It still makes me nervous in general, though. (having augmentation strings would also allow us to remove a special-case in macOS support -- we have a couple of solibs with hand-written assembly and hand-written eh_frame for it, and we special case those libraries to say "trust the eh_frame from this one, it's cool".) I've never pushed hard for the idea of adding augmentation strings from the producers because it seemed easier to depend primarily on the instruction analysis methods. But maybe it is something we should pursue. None of this really comments specifically on the proposed patch, just talking out loud about my feelings on all of this. One thing you mentioned is that the x86 instruction analysis doesn't handle multiple epilogues -- it should do that? I fixed a bug in it three weeks ago where it didn't understand an epilogue-ending tail-call JMPQ as the final instruction in the epilogue (to a noreturn function). UnwindAssemblyInstEmulation takes a much better approach where it forwards the unwind state to branches in the function and doesn't bother trying to recognize the instructions in an epilogue; that's definitely superior and what the x86 unwinder should do (or just fold it into the InstEmulation system). But in general, multiple epilogues should be handled I believe.. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82378/new/ https://reviews.llvm.org/D82378 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
