[lldb-dev] Use lldb.so to create stack trace

[Tamas Berghammer]

Hi David,

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).

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.)

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.

Tamas

On Tue, Jul 28, 2015 at 11:33 AM David Jones <djones at xtreme-eda.com> wrote:

> This works if all you want to do is print the stack trace.
>
> However, if you wish to examine or modify the trace in ANY WAY, then
> LLVM's printStackTrace() is no longer sufficient.
>
> 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.
>
> 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.
>
> 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.
>
>
> On Tue, Jul 28, 2015 at 1:13 AM, Zachary Turner <zturner at google.com>
> wrote:
>
>> 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.
>>
>> On Mon, Jul 27, 2015 at 10:12 PM Schlottke-Lakemper, Michael <
>> m.schlottke-lakemper at aia.rwth-aachen.de> wrote:
>>
>>> Hi folks,
>>>
>>> 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.
>>>
>>> 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
>>>
>>> - has someone here done or seen something like this before?
>>> - is there a tutorial for linking to lldb.so and making use of it
>>> through C++?
>>> - would this also work when compiling with other compilers than clang?
>>>
>>> Any help or pointers to relevant projects/documentation etc is greatly
>>> appreciated!
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>> --
>>> Michael Schlottke-Lakemper
>>>
>>> SimLab Highly Scalable Fluids & Solids Engineering
>>> Jülich Aachen Research Alliance (JARA-HPC)
>>> RWTH Aachen University
>>>
>>> Wüllnerstraße 5a
>>> 52062 Aachen
>>> Germany
>>>
>>> Phone: +49 (241) 80 95188
>>> Fax: +49 (241) 80 92257
>>> Mail: m.schlottke-lakemper at aia.rwth-aachen.de
>>> Web: http://www.jara.org/jara-hpc
>>> <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=>
>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150728/52c35aba/attachment.html>