On Thu, Sep 08, 2016 at 10:33:25AM -0400, Vijay Bellur wrote:
> On Thu, Sep 8, 2016 at 9:07 AM, Jeff Darcy <[email protected]> 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 libraries - such as translators, where most of our code lives.  They 
> > give us the object plus offset from where the object was loaded into 
> > memory, which isn't that easy to turn into a function name (let alone a 
> > file and line number).  It seems like libunwind can do better, getting at 
> > least to the function name.  AFAICT it's supported and packaged on all of 
> > our platforms, though there might be version differences.  Newer versions 
> > can supposedly get to file and line, which would be even better.  Before I 
> > get further into this, two questions for all of you:
> >
> > (1) Has somebody already gone down this path?  Does it work?
> >
> > (2) Are there any other reasons we wouldn't want to switch?
> 
> 
> Cannot think of any. The BSD platforms seem to have libunwind and Mac
> OS X doesn't have it apparently [1].
> 
> I have been thinking of fixing the recent Mac OS X compilation
> problems and can address issues related to libunwind as part of that
> activity.

I think libunwind support should be optional, and by default our
./configure fails if --without-libunwind is not given. Possibly there is
an alternative for Mac OS X, but it is not an OS we currently see a lot
of users with, so missing some debugging there is not critical.

Niels


> 
> -Vijay
> 
> [1] http://comments.gmane.org/gmane.comp.lib.unwind.devel/2199
> _______________________________________________
> Gluster-devel mailing list
> [email protected]
> http://www.gluster.org/mailman/listinfo/gluster-devel

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Gluster-devel mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-devel

Reply via email to