[lldb-dev] eh_frame or debug_frame

Joerg Sonnenberger joerg at britannica.bec.de
Wed Oct 15 15:58:13 PDT 2014


On Wed, Oct 15, 2014 at 02:33:08PM -0700, Jason Molenda wrote:
> 
> > On Oct 15, 2014, at 2:21 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
> > 
> > On Wed, Oct 15, 2014 at 01:44:03PM -0700, Greg Clayton wrote:
> >> 
> >>> On Oct 15, 2014, at 11:24 AM, Ryan Brown <ribrdb at google.com> wrote:
> >>> 
> >>> I'm actually struggling with this right now. I'm trying to implement an OS plugin so goroutines show up as threads.
> >>> The go compiler puts instruction accurate unwind info into .debug_frame, I'm not sure what (if anything) goes into eh_frame.
> >>> However lldb uses the disassembly instead of the dwarf info. The x86 unwinder assumes that all threads have the same LLDB register numbers, but other parts of the code require that the LLDB register number is < (number of registers). Goroutines only store sp and ip, so it seems I'm going to have to create a custom RegisterContext subclass to get the existing unwinder to work for goroutines.
> >>> 
> >> 
> >> As Jason said,  there is nothing in the EH frame or .debug_frame that
> >> says "I only have partial info that is only valid at callsites" or
> >> "I have complete unwind info". So we don't know when to trust the
> >> unwind info for frame zero.
> > 
> > I thought the rule was "if you can access .debug_frame and it is
> > available for the IP, use it, otherwise fallback to .eh_frame".
> 
> 
> With gcc/clang, we've found that eh_frame and debug_frame were identical
> so we never bothered to read debug_frame -- on the platforms where lldb
> is running today, eh_frame and debug_frame are either both present or
> both absent.  We could certainly start reading debug_frame if it is
> available and eh_frame isn't.

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.

Joerg



More information about the lldb-dev mailing list