On 07.09.2019 00:14, Thomas Klausner wrote: > On Fri, Sep 06, 2019 at 09:19:49PM +0200, Kamil Rytarowski wrote: >> On 06.09.2019 21:02, Kamil Rytarowski wrote: >>> On 06.09.2019 20:57, Thomas Klausner wrote: >>>> On Fri, Sep 06, 2019 at 08:01:13PM +0200, Kamil Rytarowski wrote: >>>>> On 06.09.2019 19:46, Thomas Klausner wrote: >>>>>> On Fri, Sep 06, 2019 at 03:11:55PM +0200, Kamil Rytarowski wrote: >>>>>>> The only supported combination is: >>>>>>> >>>>>>> HAVE_LLVM=yes MKSANITIZER=yes MKGCC=no MKLLVM=yes >>>>>> >>>>>> So I tried the suggested combination, and it didn't work for me either. >>>>>> >>>>>> --- dependall-libLLVMAsmParser --- >>>>>> In file included from /usr/src/external/bsd/llvm/librt/libLLVMAsmParser/../../lib/../dist/llvm/lib/AsmParser/LLLexer.cpp:14: >>>>>> In file included from /usr/src/external/bsd/llvm/librt/libLLVMAsmParser/../../lib/../dist/llvm/lib/AsmParser/LLLexer.h:18: >>>>>> In file included from /usr/src/external/bsd/llvm/librt/libLLVMAsmParser/../../lib/../dist/llvm/include/llvm/ADT/APFloat.h:20: >>>>>> In file included from /usr/src/external/bsd/llvm/librt/libLLVMAsmParser/../../lib/../dist/llvm/include/llvm/ADT/APInt.h:19: >>>>>> /usr/src/external/bsd/llvm/librt/libLLVMAsmParser/../../lib/../dist/llvm/include/llvm/Support/Compiler.h:387:11: fatal error: 'sanitizer/asan_interface.h' file not found >>>>>> # include <sanitizer/asan_interface.h> >>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>> >>>>>> build.sh -j 16 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -V MKSANITIZER=yes -V HAVE_LLVM=yes -V MKGCC=no -T /usr/obj/tools.clang -m amd64 -O /usr/obj/src.amd64 -D /usr/obj/amd64.clang.20190906 -R /usr/obj/amd64.clang.20190906.release distribution >>>>>> >>>>>> Thomas >>>>>> >>>>> >>>>> Was this a clean build? >>>> >>>> Yes, this happens with an empty DESTDIR, and 'cvs update' was not >>>> complaining about any files lying around. >>>> Thomas >>>> >>> >>> I have reproduced it. I'm going to investigate it and fix. >>> >>> It looks like for some reason clang sanitizer files are not copied into >>> tooldir. >>> >> >> OK, I know what is wrong. MKLLVMRT / X is enabled and this sequence of >> build wasn't tested and needs correction. >> >> For the time being, I recommend to remove the "-x" option from build.sh >> as there are bigger tasks to do at this point before running sanitized X. > > Well, I don't need a sanitized X, I just wanted a sanitizing compiler. Sanitizing compiler is available without MKSANITIZER. > Anyway, I followed your suggestion and updated my system. > > I still had programs installed (from the 9.99.10 without MKSANITIZER). > Running them I see stuff like this: > > # hg up -C TNF > /usr/lib/libutil.so.7: Undefined symbol "__asan_option_detect_stack_use_after_return" (symnum = 94) > # ls -l /usr/lib/libutil* > -r--r--r-- 1 root wheel 222060 Sep 6 22:03 /usr/lib/libutil.a > lrwxr-xr-x 1 root wheel 25 Sep 6 22:03 /usr/lib/libutil.so -> ../../lib/libutil.so.7.24 > lrwxr-xr-x 1 root wheel 25 Sep 6 22:03 /usr/lib/libutil.so.7 -> ../../lib/libutil.so.7.24 > lrwxr-xr-x 1 root wheel 25 Sep 6 22:03 /usr/lib/libutil.so.7.24 -> ../../lib/libutil.so.7.24 > -r--r--r-- 1 root wheel 518486 Sep 6 22:03 /usr/lib/libutil_g.a > -r--r--r-- 1 root wheel 230302 Sep 6 22:03 /usr/lib/libutil_p.a > # ls -l /lib/libutil* > lrwxr-xr-x 1 root wheel 15 Sep 6 22:03 /lib/libutil.so -> libutil.so.7.24 > lrwxr-xr-x 1 root wheel 15 Sep 6 22:03 /lib/libutil.so.7 -> libutil.so.7.24 > -r--r--r-- 1 root wheel 415608 Sep 6 22:03 /lib/libutil.so.7.24 > # ldd /lib/libutil.so > /lib/libutil.so: > -lc.12 => /lib/libc.so.12 > # ls -l /lib/libc.so.12* > lrwxr-xr-x 1 root wheel 14 Sep 6 21:59 /lib/libc.so.12 -> libc.so.12.213 > -r--r--r-- 1 root wheel 2178936 Sep 6 21:59 /lib/libc.so.12.213 > > Or > /usr/lib/libz.so.1: Undefined symbol "__asan_option_detect_stack_use_after_return" (symnum = 42) > > What is the problem here? libutil is built with a sanitizer. This means that the code in libutil is instrumented and contains calls to sanitizer runtime. The runtime is linked into programs, not libraries. This means that there is need to build each program in this setup with a sanitizer. Every application that dynamically links with an instrumented library has to be prebuilt with a sanitizer. > Do I have to recompile all of pkgsrc, and if yes, why? Basically yes, there is need to recompile all of pkgsrc. There could be probably some work arounds with LD_PRELOAD and a dummy sanitizer runtime.. however certainly better to invest into sanitized pkgsrc build configuration. My workaround for breaking applications is to build programs statically or use the version from /rescue. However ASan and UBSan can be often used on the top of non-sanitized libraries and this will work decently finding problems in an application, but skipping issues called in libraries. MSan and TSan are more sensitive here and need full sanitization. > Thomas > So summary: sanitizers are quick and accurate in bug detection; but in certain setups there is still room for valgrind that takes prebuilt native code and instruments it its virtual machine, on the cost of being extremely slow and with more false negatives.
Attachment:
signature.asc
Description: OpenPGP digital signature