On Wed, Oct 15, 2014 at 02:33:08PM -0700, Jason Molenda wrote: > > > On Oct 15, 2014, at 2:21 PM, Joerg Sonnenberger <jo...@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 <rib...@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 _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
