> On Oct 10, 2014, at 1:58 PM, Francois Pichet <pichet2...@gmail.com> wrote: > > > > On Fri, Oct 10, 2014 at 4:20 PM, Greg Clayton <gclay...@apple.com> wrote: > > > On Oct 10, 2014, at 1:05 PM, Philippe Lavoie <philippe.lav...@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. _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
