On 13/04/16 14:41, Emil Velikov wrote:
Hi Jose,
On 12 April 2016 at 17:03, Jose Fonseca <[email protected]> wrote:
libasan is never linked to shared objects (which doesn't go well with
-z,defs). It must either be linked to the main executable, or (more
practically for OpenGL drivers) be pre-loaded via LD_PRELOAD.
Otherwise works.
I didn't find anything with llvmpipe. I suspect the fact that the
JIT compiled code isn't instrumented means there are lots of errors it
can't catch.
But for non-JIT drivers, the Address/Leak Sanitizers seem like a faster
alternative to Valgrind.
Usage (Ubuntu 15.10):
scons asan=1 libgl-xlib
export
LD_LIBRARY_PATH=$PWD/build/linux-x86_64-debug/gallium/targets/libgl-xlib
LD_PRELOAD=libasan.so.2 any-opengl-application
Just a bit of more info for anyone unfamiliar/interested. Not meant to
stir the waters.
Traditionally, the sanitizers were static libraries that one used for
link in each binary. As of recently one can opt for the shared library
libasan.so. Imho should opt against using the shared lib pro temp. as
it has multiple drawbacks (experimental, unsupported, has worse
performance ...) [1].
-Emil
[1] https://github.com/google/sanitizers/wiki/AddressSanitizerAsDso
I managed to link asan statically, but it doesn't work.
This is because we often need to free() things from other libraries
(Xlib) and vice-versa, and it will crash as soon as that happens.
For the record, my patch for statically linking asan was something like:
+ if env['asan']:
+ if gcc_compat:
+ env.Append(CCFLAGS = [
+ '-fsanitize=address',
+ ])
+ env.Append(LINKFLAGS = [
+ '-fsanitize=address',
+ '-static-libasan',
+ ])
+ env['_LIBFLAGS'] = env['_LIBFLAGS'] + ' -Wl,-Bstatic -lasan
-Wl,-Bdynamic'
+ env.Append(LIBS = ['asan'])
+
Maybe statically linking the asan is better, but only when talking about
the main program. But in mesa we build the drivers, not the main program.
Jose
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
