[lldb-dev] eh_frame or debug_frame

[Jason Molenda]

> On Oct 15, 2014, at 2:21 PM, Joerg Sonnenberger <joerg at 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 <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.
> 
> 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.