Displaying 4 results from an estimated 4 matches for "__msan_memcpy".
2015 Jan 21
2
[LLVMdev] Shared libraries, msan and -z,defs
...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
initializat...
2015 Jan 22
2
[LLVMdev] Shared libraries, msan and -z,defs
...e library search path.
> Which is the common situation, unless you install clang as a
> system-wide compiler. This will create lots of deployment problems.
True, but it's only a headache for people using -z defs.
I'm surprised there isn't a linker option we can use like '-u
__msan_memcpy' to say "yeah, this symbol is undefined, but it's expected to
be present at runtime".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150122/4f49fa02/attachment.html>
2018 Sep 21
2
msan test failures
...san/tests/msan_test_main.cc:19:3
#15 0x7fd75b533222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
#16 0x46740d in _start
(/home/blitz/projects/bllvm/projects/compiler-rt/lib/msan/tests/Msan-x86_64-with-call-Test+0x46740d)
Uninitialized value was stored to memory at
#0 0x470553 in __msan_memcpy.part.350
/home/blitz/projects/llvm/projects/compiler-rt/lib/msan/msan_interceptors.cc:1488:3
#1 0x7aadab in std::__1::char_traits<char>::copy(char*, char const*,
unsigned long)
/home/blitz/projects/llvm/projects/libcxx/include/__string:225:50
#2 0x7aadab in std::__1::basic_string<c...
2015 Jan 21
5
[LLVMdev] Shared libraries, msan and -z,defs
> 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