[lldb-dev] eh_frame or debug_frame

Greg Clayton gclayton at apple.com
Mon Oct 13 09:55:03 PDT 2014


> On Oct 10, 2014, at 1:58 PM, Francois Pichet <pichet2000 at gmail.com> wrote:
> 
> 
> 
> On Fri, Oct 10, 2014 at 4:20 PM, Greg Clayton <gclayton at apple.com> wrote:
> 
> > On Oct 10, 2014, at 1:05 PM, Philippe Lavoie <philippe.lavoie at octasic.com> wrote:
> >
> > Hi,
> >
> > I noticed that by default lldb does not read .debug_frame section to unwind frames but relies instead on .eh_frame .
> >
> > Is there a way to fallback to reading .debug_frame?
> 
> Not currently. Most compilers (gcc _and_ clang) put the same old stuff in .debug_frame as they do in .eh_frame, so we haven't had to use .debug_frame over .eh_frame yet. What compiler are using that is putting different (more complete) info in .debug_frame vs .eh_frame?
> 
> 
> What about about C or C++ program compiled with -fno-exceptions? 
> They will fall back to the UnwindAssembly way even if the .debug_frame is present right?

If no EH frame exists for a frame, then we will always fall back to UnwindAssembly. We always use UnwindAssembly for the first frame and for any frame that is past an async interrupt (sigtramp). We use the EH frame/.debug_frame for any non-zero frames, but will always use UnwindAssembly if there is no such info.






More information about the lldb-dev mailing list