On 09.12.2017 20:11, Valery Ushakov wrote: > Kamil Rytarowski <n54%gmx.com@localhost> wrote: > >> The problem is not on the header files (preprocessor), but on the linker >> level. >> >> We are linking prebuilt .a / .so files with a target application. >> >> $ nm >> /usr/local/lib/clang/6.0.0/lib/netbsd/libclang_rt.msan-x86_64.a|grep uname >> 0000000000000000 B _ZN14__interception10real_unameE >> 0000000000000000 T __interceptor_uname >> 0000000000000000 T uname >> >> We are intercepting uname(3) because behind the scenes it's a syscall >> and we need to hardcode sanitizing rules (length of a field that is >> being initialized). > > Why it's an .a and not an .so, where you can play symbol interception > tricks? > > -uwe > Some sanitizers can be used as .so files: asan, scudo, ubsan. I don't know the exact reason why there is no msan or tsan (profile, fuzzer, safestack, stats, lsan...), but .a files are simpler to implement and it's easier to bootstrap them before being able to get dlsym(3) or other functions to work with symbols to work.
Attachment:
signature.asc
Description: OpenPGP digital signature