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