[LLVMdev] Shared libraries, msan and -z,defs

[Reid Kleckner]

The sanitizer libc interceptors (malloc, etc) also need to be linked into
the executable because the loader searches the executable first.

I think the sanitizers also rely on the initial executable TLS model.

Given the complexities, I don't think it's worth the effort to split. It
might be worth it if there were more desire to support the shared library
sanitizer build that GCC prefers.

What about creating an msan interface DSO for the purposes of satisfying -z
defs? The executable will always be searched first, so the interface DSO
could be empty or full of ud2a.

On Wed, Jan 21, 2015 at 5:59 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> I recently tried to enabled building llvm libraries with -Wl,-z,defs.
> The intention was to detect missing dependencies on ELF, so that we
> don't
> get into a situation where a .so builds, but the equivalent .dylib or
> .dll fails.
>
> This failed when building with msan because of undefined references to
> functions like __msan_memcpy.
>
> Unfortunately, I don't think elf linkers have a way of informing them
> that a given symbol will be provided at runtime. It is possible to
> pass a dummy executable build with msan, but that gets recorded in
> DT_NEEDED.
>
> My understanding is that the msan library provides two things: an
> initialization code that has to run really early and auxiliary
> functions like __msan_memcpy.
>
> Would it be possible to split libclang_rt.msan-x86_64.a such that the
> utility functions are available on a .so (or at least a -fPIC .a)?
> That library could be linked with every .so. The early init logic
> would still only be linked with executables.
>
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150121/36f067f0/attachment.html>