<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 10, 2014 at 4:20 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
> On Oct 10, 2014, at 1:05 PM, Philippe Lavoie <<a href="mailto:philippe.lavoie@octasic.com">philippe.lavoie@octasic.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I noticed that by default lldb does not read .debug_frame section to unwind frames but relies instead on .eh_frame .<br>
><br>
> Is there a way to fallback to reading .debug_frame?<br>
<br>
</span>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?<br>
<span class=""><br><br></span></blockquote><div>What about about C or C++ program compiled with -fno-exceptions? </div><div>They will fall back to the UnwindAssembly way even if the .debug_frame is present right?</div><div><br></div></div><br></div></div>