[lldb-dev] eh_frame or debug_frame

[Greg Clayton]

> 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. If the go compiler always generates complete .debug_frame, you should mark it somehow so we can know to trust it at all locations. By default we would set the "m_is_complete" to false, but you can set it to "true" when the language for the compile unit is Go.

Then we would need to make the unwinder always try to get unwind for frame zero and ask it if it is complete. If so, use it, else fall back to doing assembly unwind.

Greg