llvm dev - Jan 2015 - [LLVMdev] Shared libraries, msan and -z,defs

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

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>

> 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.
I like the idea. The ideal solution would probably be for the linkers
to have a --not-needed command line option that prevents the .so from
going in the DT_NEEDED, but one with just stubs is probably fine.

Cheers,
Rafael