[llvm-dev] Using MSan as dso

[Mitch Phillips via llvm-dev]

Hi Marko,

> Since MSan is usable as dso it would be very nice if you could patch
/compiler-rt-$(VERSION).src/lib/msan/CMakeLists.txt in order to generate
msan.so when compiling llvm from source (similar as for ASan or UBSan).

Given that this is a completely-unsupported model, I'd rather not do this.

> Also, I believe there is a mistake in MSan documentation where it's said
that static linking with MSan is not supported.

Slightly confusing wording, but the documentation means to say "MSan is not
supported for static executables."

> I have situation where I want to use MSan with mixed code
(Python->swig.cxx->native.so, as mentioned it is possible for ASan here),
I'm using clang 7.0.1 and I keep getting DEADLYSIGNAL from MSan when trying
to use it in that way.

I'm sorry - I'm not able to provide much help with this unsupported use
case. I'm not surprised things are breaking :(.

On Thu, Apr 8, 2021 at 2:42 AM Marko Stanojlovic <
Marko.Stanojlovic at syrmia.com> wrote:

> Hi Mitch,
>
> Thank you for quick response.
> Since MSan is usable as dso it would be very nice if you could
> patch /compiler-rt-$(VERSION).src/lib/msan/CMakeLists.txt in order to
> generate msan.so when compiling llvm from source (similar as for ASan or
> UBSan).
>
> Also, I believe there is a mistake in MSan documentation
> <https://clang.llvm.org/docs/MemorySanitizer.html#limitations> where it's
> said that static linking with MSan is not supported.
>
> I have situation where I want to use MSan with mixed code
> (Python->swig.cxx->native.so, as mentioned it is possible for ASan here
> <https://github.com/google/sanitizers/wiki/AddressSanitizerAsDso#asan-and-ld_preload>),
> I'm using clang 7.0.1 and I keep getting DEADLYSIGNAL from MSan when trying
> to use it in that way.
>
> Error message:
>
> MemorySanitizer:DEADLYSIGNAL
> ==17609==ERROR: MemorySanitizer: stack-overflow on address 0x7fffdd85afe8
> (pc 0x7fbe5c948e34 bp 0x7fffdd85b050 sp 0x7fffdd85afe0 T17609)
> MemorySanitizer:DEADLYSIGNAL
> MemorySanitizer: nested bug in the same thread, aborting.
>
> When I'm using ASan in the same way it works as expected.
>
> Kind regards,
> Marko Stanojlović
>
> SYRMIA LLC @ Belgrade Office Park
> Djordja Stanojevica 12,
> Beograd 11070
>
>
>
> ------------------------------
> *From:* Mitch Phillips <mitchp at google.com>
> *Sent:* Wednesday, April 7, 2021 9:09 PM
> *To:* Marko Stanojlovic <Marko.Stanojlovic at syrmia.com>
> *Cc:* llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] Using MSan as dso
>
> Hi Marko,
>
> Uninstrumented code under ASan leads to false negatives. Under MSan,
> uninstrumented code leads to false positives. MSan is thus not suitable to
> be used as a preloaded DSO.
>
> If you're really, really, extremely dedicated and willing to annotate
> <https://clang.llvm.org/docs/MemorySanitizer.html#blacklist> *every* instance
> where memory that's initialized in uninstrumented code flows to
> instrumented code, then you might be able to find some bugs. But it's worth
> bearing in mind that usage of MSan in this way is warranty-voiding.
>
> On Wed, Apr 7, 2021 at 12:01 PM Marko Stanojlovic via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hello llvm developers,
>
> Is there a way to use Memory Sanitizer when there is a third-party
> executable which cannot be recompiled,
> but it loads shared libraries that can be recompiled and we want to test
> them with MSan? In other words could be MSan used as dso?
> Similar to ASan usage described on its wiki page -
> https://github.com/google/sanitizers/wiki/AddressSanitizerAsDso.
>
> Kind regards and thanks in advance for response,
> Marko Stanojlović
>
> SYRMIA LLC @ Belgrade Office Park
> Djordja Stanojevica 12,
> Beograd 11070
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210408/96e774be/attachment.html>