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
_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
