Re: [Libunwind-devel] Patching the stack trace obtained by libunwind?

[Kirill Müller]

On 21.09.2017 17:13, Dave Watson wrote:
> On 09/09/17 10:42 AM, Kirill Müller wrote:
> > Hi
> >
> >
> > When developing for a script language that also supports native code (such
> > as R or Python), it would be great to see an ensemble backtrace that
> > contains source information in terms of the scripted language co-mingled
> > with the native stack trace. One option to do this would be to support hooks
> > that would patch the backtrace reported by libunwind. Would this be
> > worthwhile exploring?
> >
> > I don't know anything about libunwind's internals, a quick scan of its API
> > and the last year's mailing list archives did not reveal anything in this
> > direction. Thank you for a short feedback.
>
> Have you looked at the dynamic support yet?
>
> http://www.nongnu.org/libunwind/man/libunwind-dynamic(3).html
>
> It's been a while since I looked at it, I know some pieces of the
> support are missing on some platforms.
>
> Alternatively, you could emit dwarf info for the scripting language.
Thanks, I've briefly looked into dynamic support, but this and emitting 
dwarf info seems to be most appropriate for generators of machine code. 
Would they work for an interpreted language, where the true call stack 
may be a sequence of recursive calls to an eval() function that executes 
interpreted code?

Both R and Python support processing the call stack at the language 
level, but this stops when they call into native code. When debugging or 
profiling such native code, it would be very useful to see the call 
stack of the scripted language (before the call into native code) at the 
language level.


-Kirill