Bruno Haible [2025-10-23 01:59 +0200] wrote: > The right way to do so is: > > # Cf. https://clang.llvm.org/docs/AddressSanitizer.html
[ This document hasn't been meaningfully updated in years, is brief, and has open patches/reports for docfixes on the LLVM tracker. I tend to also check the Google wiki[0] and search the LLVM issue tracker, where I often find undocumented details. ] [0]: https://github.com/google/sanitizers/wiki/AddressSanitizer > CC="clang -Wl,-rpath,$CLANG_INSTALLATION_DIR/lib -fsanitize=address" Is it sufficient to specify the -rpath, without the need for the LD_PRELOAD hack (see below)? > export CC > CFLAGS="-O0 -fno-omit-frame-pointer -ggdb" [ Just to be clear, these CFLAGS should be needed only for debugging. ] > export CFLAGS > > You are getting nonsense results because > 1) you are not passing the documented option '-fsanitize=address' I am, in configure.ac. > but instead playing with libclang_rt in undocumented ways, It's a hack, but it's the only documented way to load an instrumented shared object into an uninstrumented binary: - https://github.com/google/sanitizers/wiki/AddressSanitizerAsDso - https://github.com/google/sanitizers/issues/1086 - https://github.com/llvm/llvm-project/issues/41522 Context: I was originally trying to build an Emacs dynamic module with ASan, and have it loaded by an uninstrumented Emacs. At some point while I was figuring out the LD_PRELOAD dance, I must have mistakenly discovered that limiting the scope of LD_PRELOAD and ASAN_OPTIONS avoided certain errors, but I hadn't noticed the errors in config.log that Collin pointed out. > 2) the environment variables LD_PRELOAD and ASAN_OPTIONS are not > active during the 'configure' step. > > Both of these mistakes are fatal. Right, thanks to both you and Collin for pointing out my mistakes, and sorry for the noise. I get the behaviour I expect when I export LD_PRELOAD and ASAN_OPTIONS before the configure step. -- Basil
