[lldb-dev] eh_frame or debug_frame

Wed Oct 15 11:48:14 PDT 2014

Yes, I'm writing a class to do that now. It's just not supported by any of
the existing register contexts.

-- Ryan Brown

On Wed, Oct 15, 2014 at 11:37 AM, Jason Molenda <jason at molenda.com> wrote:

> Can't your OS plugin for the goroutines use the same sp and ip register
> numbers as x86_64 (instead of 0 and 1 like you might be using right now)
> when it reports them to lldb, and return all the other registers as
> "unavailable" if they're requested?
>
> The tricky bit about living on eh_frame / debug_frame is that lldb doesn't
> know what kind of unwind info it is being given.  Is it just for exception
> handling locations?  Does it contain prologue setup?  epilogue?  Is it
> fully asynchronous - giving unwind details at all locations?  There aren't
> any flags in eh_frame/debug_frame that could give us a hint about what
> we're working with.
>
>
>
> 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.
> >
> > On Tue, Oct 14, 2014 at 5:51 PM, Jason Molenda <jmolenda at apple.com>
> wrote:
> > > On Oct 13, 2014, at 9:55 AM, Greg Clayton <gclayton at apple.com
> > > wrote:
> >
> > >
> >
> >
> > >
> >
> >
> > >> On Oct 10, 2014, at 1:58 PM, Francois Pichet <pichet2000 at gmail.com
> > > wrote:
> >
> > >>
> >
> >
> > >>
> >
> >
> > >>
> >
> >
> > >> On Fri, Oct 10, 2014 at 4:20 PM, Greg Clayton <gclayton at apple.com
> > > wrote:
> >
> > >>
> >
> >
> > >>> On Oct 10, 2014, at 1:05 PM, Philippe Lavoie <philippe.lavoie at
> octasic.com
> > > wrote:
> >
> > >>>
> >
> >
> > >>>
> >  Hi,
> >
> > >>>
> >
> >
> > >>>
> >  I noticed that by default lldb does not read .debug_frame section to
> unwind frames but relies instead on .eh_frame .
> >
> > >>>
> >
> >
> > >>>
> >  Is there a way to fallback to reading .debug_frame?
> >
> > >>
> >
> >
> > >>
> >  Not currently. Most compilers (gcc _and_ clang) put the same old stuff
> in .debug_frame as they do in .eh_frame, so we haven't had to use
> .debug_frame over .eh_frame yet. What compiler are using that is putting
> different (more complete) info in .debug_frame vs .eh_frame?
> >
> > >>
> >
> >
> > >>
> >
> >
> > >>
> >  What about about C or C++ program compiled with -fno-exceptions?
> >
> > >>
> >  They will fall back to the UnwindAssembly way even if the .debug_frame
> is present right?
> >
> > >
> >
> >
> > >
> >  If no EH frame exists for a frame, then we will always fall back to
> UnwindAssembly. We always use UnwindAssembly for the first frame and for
> any frame that is past an async interrupt (sigtramp). We use the EH
> frame/.debug_frame for any non-zero frames, but will always use
> UnwindAssembly if there is no such info.
> >
> >
> >
> > I want to expand on what Greg said earlier about eh_frame versus
> debug_frame.
> >
> > Ideally, eh_frame will be the minimal unwind instructions necessary to
> unwind the stack when exceptions are thrown/caught.  eh_frame will not
> include unwind instructions for the prologue instructions or epilogue
> instructions -- because we can't throw an exception there, or have an
> exception thrown from a called function "below" us on the stack.  We call
> these unwind instructions "synchronous" because they only describe the
> unwind state from a small set of locations.
> >
> > debug_frame would describe how to unwind the stack at every instruction
> location.  Every instruction of the prologue and epilogue.  If the code is
> built without a frame pointer, then it would have unwind instructions at
> every place where the stack pointer is modified.  We describe these unwind
> instructions as "asynchronous" because they describe the unwind state at
> every instruction location.
> >
> >
> > Instead what we have with gcc and clang is eh_frame instructions that
> describe the prologue (and some versions of gcc, the epilogue) plus the
> unwind state at synchronous unwind locations (where an exception can be
> thrown).  We have a half-way blend of asynchronous and synchronous ... it's
> "pretty good" but not "guaranteed" from a debugger's perspective.  It would
> be great if eh_frame was genuinely only the unwind instructions for
> exception handling and debug_frame had the full unwind state at every
> instruction and we could depend on debug_frame.  But in reality, the same
> unwind instructions are put in both eh_frame and debug_frame -- so there's
> little point in ever reading debug_frame.  lldb does not read debug_frame
> today, although it would be easy to do so.
> >
> >
> > As an experiment starting late August (r216406), lldb is now trying to
> use eh_frame for the currently-executing frame.  Even though it isn't
> *guaranteed* to be accurate at all instructions, in practice it's pretty
> good -- good enough that gdb seems to be able to live on it.  Tong Shen's
> patch in r216406 does augment the eh_frame unwind instructions with the
> epilogue unwind... newer gcc's apparently describe the epilogue in eh_frame
> but few other compilers do.
> >
> > It's an open question how well living off eh_frame unwind instructions
> will work with a non-gcc/non-clang compiler.  That's why I say this is an
> "experiment" - we may have to revert to lldb's UnwindAssembly profiling
> code for the currently-executing function if this breaks with other
> compilers.
> >
> > J
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141015/26a71733/attachment.html>