[PATCH] Use libbacktrace as libsanitizer's symbolizer

[Jakub Jelinek]

On Mon, Nov 18, 2013 at 10:26:58AM -0800, Ian Lance Taylor wrote:
> On Mon, Nov 18, 2013 at 9:09 AM, Ian Lance Taylor <iant@google.com> wrote:
> > On Mon, Nov 18, 2013 at 5:39 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> >
> >> 3) I wonder if libbacktrace couldn't be updated to use __atomic_* builtins,
> >>    then it could avoid the ugliness to emulate atomic loads and stores.
> >
> > I think that would be fine.  I can't remember why I didn't use the
> > __atomic builtins.  Maybe they weren't quite ready at the time.
> 
> Wait, I remember the reason.  It's because we compile libbacktrace
> with the host compiler so that it can be linked with GCC itself, and
> it seems premature to assume that the host compiler supports the
> __atomic builtins.

Sure, but GCC itself doesn't need the thread-safe stuff, and the target
libbacktrace is built with gcc and will have __atomic_* support.
You already have there configure checks for the __sync_* builtins, just
replacing them with the __atomic_* stuff would DTRT.
> 
> Of course we could use configure tests and so forth, but the code to
> implement atomic loads using the sync builtins is simple enough that
> I'm not sure it's worth it.

It should be (at least on most targets) faster to use
__atomic_load/__atomic_store, plus you could make it explicit what
is an acquire, what is release semantics, what needs sequentially consistent
atomic etc.  And it would be more readable.

Anyway, seems that in the latest libsanitizer code it uses locking around
the symbolizer anyway, so from libsanitizer POV there won't be a need to use
the thread safe variant.

	Jakub