<div dir="ltr">Hi David,<div><br></div><div>I am interested about what you can achieve with your approach because we are planing to do something similar for Android in the future (not too soon).</div><div><br></div><div>Based on my understanding there are a few issues you have to handle in your current setup. First of all unwinding in LLDB isn't as reliable as it should be especially if we don't have full debug info. This can cause some flakiness in your output and can explain why you don't see the backtrace past the signal handler. There are some work going on to improve the general unwinding code but there are a lot of outstanding edge cases. The pause at startup time is most likely caused by symbol loading and dwraf parsing. Currently LLDB try to do it lazily but it isn't working as expected and a lot of information is loaded what you won't use for your limited feature set. You can try to optimize these issues in LLDB but I am not sure if you can get the required performance. (Depending on which version of LLDB you use you might also spawn an lldb-server instance when doing the attach.)</div><div><br></div><div>I think the best solution would be to write a library similar to libunwind based on LLDB and put it into the LLDB codebase so it can rely on the internal data structures because currently that is the only way you can get rid of all performance hit imposed by the other parts of LLDB what you don't use. It is a bigger task but if you would like to go this way then let me know and I am happy to discuss it.</div><div><br></div><div>Tamas</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 28, 2015 at 11:33 AM David Jones <<a href="mailto:djones@xtreme-eda.com">djones@xtreme-eda.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>This works if all you want to do is print the stack trace.<br><br></div>However, if you wish to examine or modify the trace in ANY WAY, then LLVM's printStackTrace() is no longer sufficient.<br><br></div>In my case, my language mangles names in its own way, because it is not C++. I need to demangle these names, and therefore need to examine/modify the output.<br><br></div>Right now I am forking, launching LLDB in the parent, and attaching to my compiler in the child, and when LLDB gets notified of a signal, I print the stack trace. This is essentially what the OP wanted. This works, but there is a pause at startup while LLDB does??? (I think it's loading symbols). I'd like to get rid of that pause, but have found no workable way of doing so.<br><br></div>One idea I had was to have LLDB launch only after my signal handler has caught a signal. Alas, in this mode, LLDB could not backtrace past the signal handler - all stack frames from my compiled code were dropped, so that it looked like the code that generated the signal was in fact my runtime.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 28, 2015 at 1:13 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Instead of linking lldb.so, which is basically an entire debugger, maybe you could just link llvm? I don't remember which library has the stack trace function in llvm, but the function I believe is called llvm::sys::printStackTrace(). This will give you a much smaller overhead than bringing in all of lldb unnecessarily.</div><br><div class="gmail_quote"><span><div dir="ltr">On Mon, Jul 27, 2015 at 10:12 PM Schlottke-Lakemper, Michael <<a href="mailto:m.schlottke-lakemper@aia.rwth-aachen.de" target="_blank">m.schlottke-lakemper@aia.rwth-aachen.de</a>> wrote:<br></div></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Hi folks, <br>
<br>
We are looking for a way to use lldb.so to print out a stack trace programmatically. In our scientific simulation tool (written in C++) , we use a custom terminate function where we are already able to print stack traces in case of an abnormal abort, which uses some gcc-specific magic. <br>
<br>
My idea is to link our tool to lldb.so when compiling for debugging and to use the library to print a stack trace programmatically, including demangled names and correct line numbers. However, I don't really know how to start thus I am wondering<br>
<br>
- has someone here done or seen something like this before? <br>
- is there a tutorial for linking to lldb.so and making use of it through C++? <br>
- would this also work when compiling with other compilers than clang? <br>
<br>
Any help or pointers to relevant projects/documentation etc is greatly appreciated! <br>
<br>
Regards, <br>
<br>
Michael <br>
<br>
--<br>
Michael Schlottke-Lakemper<br>
<br>
SimLab Highly Scalable Fluids & Solids Engineering<br>
Jülich Aachen Research Alliance (JARA-HPC)<br>
RWTH Aachen University<br>
<br>
Wüllnerstraße 5a<br>
52062 Aachen<br>
Germany<br>
<br></span>
Phone: <a href="tel:%2B49%20%28241%29%2080%2095188" value="+492418095188" target="_blank">+49 (241) 80 95188</a><br>
Fax: <a href="tel:%2B49%20%28241%29%2080%2092257" value="+492418092257" target="_blank">+49 (241) 80 92257</a><br>
Mail: <a href="mailto:m.schlottke-lakemper@aia.rwth-aachen.de" target="_blank">m.schlottke-lakemper@aia.rwth-aachen.de</a><br>
Web: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jara.org_jara-2Dhpc&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=DDUMf06MYELAe1Nlv7KChiwJLLHbYha4jtK_AOiWqwQ&m=xVT0HkfeqC08Qoa93HzeQ55AmpxQb4Ecvst4ybPmxRU&s=quSM9W4gQgTeWyTwz1wYwFfT6z6UhfjDndUcvvpCeAs&e=" rel="noreferrer" target="_blank">http://www.jara.org/jara-hpc</a><br>
<br>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
</blockquote></div>
<br>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
</blockquote></div>