On Mon, Sep 12, 2016 at 09:30:32AM -0400, Jeff Darcy wrote:
> I looked into this a bit over the weekend. Unfortunately, while
> libunwind *does* get function names for calls in shared libraries, it
> *doesn't* seem to handle calls through function pointers very well.
> Imagine that original_func
I looked into this a bit over the weekend. Unfortunately, while libunwind
*does* get function names for calls in shared libraries, it *doesn't* seem to
handle calls through function pointers very well. Imagine that original_func
in your main program finds shared_lib_func via dlsym and calls
On Thu, Sep 08, 2016 at 09:07:33AM -0400, Jeff Darcy wrote:
> (1) Has somebody already gone down this path? Does it work?
I recall attempting to port the Julia programming language to
NetBSD, and libunwind gave me a hard time because the NetBSD
does not implement an API as large as on Linux.
On 09/08/2016 10:33 AM, Vijay Bellur wrote:
On Thu, Sep 8, 2016 at 9:07 AM, Jeff Darcy wrote:
In a few places in our code (e.g. gf_log_callingfn) we use the "backtrace" and
"backtrace_symbols" functions from libc to log stack traces. Unfortunately, these
functions don't
On Thu, Sep 08, 2016 at 10:33:25AM -0400, Vijay Bellur wrote:
> On Thu, Sep 8, 2016 at 9:07 AM, Jeff Darcy wrote:
> > In a few places in our code (e.g. gf_log_callingfn) we use the "backtrace"
> > and "backtrace_symbols" functions from libc to log stack traces.
> >
On Thu, Sep 08, 2016 at 09:07:33AM -0400, Jeff Darcy wrote:
> In a few places in our code (e.g. gf_log_callingfn) we use the "backtrace"
> and "backtrace_symbols" functions from libc to log stack traces.
> Unfortunately, these functions don't seem very smart about dynamically loaded
>
In a few places in our code (e.g. gf_log_callingfn) we use the "backtrace" and
"backtrace_symbols" functions from libc to log stack traces. Unfortunately,
these functions don't seem very smart about dynamically loaded libraries - such
as translators, where most of our code lives. They give us