> On Oct 15, 2014, at 3:58 PM, Joerg Sonnenberger <[email protected]> > wrote: > > If someone has sync unwind data working for LLVM, we can experiment with > the size difference for different code sets. I would expect it to make a > difference e.g. for pure C code on many architectures. Right now, there > is not much reason with GCC and Clang to choose one or the other, as you > wrote.
Yeah, I doubt the fully asynchronous unwind information would be very large. We're already putting the prologue unwind instructions in both eh_frame and debug_frame (which is completely unnecessary in eh_frame). For code using a frame pointer register (so we don't need to track all changes to the stack pointer), the prologue and epilogue(s) are the only instructions that need to be described. IIRC clang today doesn't describe the epilogue in eh_frame -- apparently modern gcc's are doing that. So for fp-code, gcc is basically emitting asynchronous unwind instructions in eh_frame today but without guarantees about it. If the compiler generated omit-frame-pointer code, so we need to see all stack pointer changes, that's where we'd see problems. Especially with i386 where we don't have pc-relative addressing, a common sequence of instructions is "call next-instruction; pop $ebx" which gives you the address of the pop instruction in register ebx and you can find pc-relative ! data by that. But if we're generating omit-frame-pointer code, that stack movement would not be described in eh_frame and the debugger won't know how to backtrace for one instruction. It sounds like a minor thing -- but if the goal is "accurate backtraces at every instruction boundary" (which is a useful goal for a debugger), it needs to be handled. There are other cases where unwinding can be tricky but if a function uses a frame pointer register most of the complicated stuff goes away. On Mac OS X we've stopped emitting eh_frame in almost all cases. For exception handling we have a home-grown scheme called compact unwind info that Nick came up with. It has a number of benefits over eh_frame - one is that you can index into it without scanning the entire section to find a function, two is that each function's unwind instructions are described with a single 32-bit value which describes how to restore registers off the stack and how to unwind out of the function. For typical compiler-generated code, compact unwind is able to fully represent the unwind details for exception handling. Obviously it doesn't describe things like the prologue or epilogue -- it is focused 100% on the "synchronous unwind" problem, for actual exception handling. lldb doesn't currently read compact unwind (we're relying on the assembly inspection parser full-time right now) but it's one of my free-weekend TODOs to add a parser. The only reason I mention it is because no one seems to care about the size of eh_frame / debug_frame these days... you'd think the size of eh_frame would be something worth worrying about given that it's paged in to binaries as they execute but that doesn't seem to be the case. J _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
