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 it via a 
function pointer, and that shared_lib_func then calls callback_func back in the 
main program.  If we try to get a backtrace at this point, glibc will give us 
this:

   callback_func
   ??? (address) in shared_lib.so
   original_func

Libunwind will give us this:

   callback_func
   shared_lib_func

Notice that the last frame (original_func) is missing.  Also, neither has file 
names or line numbers.  I did find a method that will give us those, while also 
handling both shared libraries and function pointers well: invoke gdb to run 
against the current process, using "-batch" and "-ex" to run just the backtrace 
command.  We can even get backtraces for all threads instead of just one.  I 
looked a bit into using the relevant gdb functions as a library, but didn't get 
anywhere with that.  While invoking a whole new process makes this a bit too 
heavyweight for most cases, for the case where we're about to exit anyway 
(which is where this all started for me) it might be pretty useful.
_______________________________________________
Gluster-devel mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-devel

Reply via email to