> 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. _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
