[PATCH] D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines.

[Evgenii Stepanov via Phabricator via llvm-commits]

eugenis added a comment.

In D75390#1908166 <https://reviews.llvm.org/D75390#1908166>, @clayborg wrote:

> In D75390#1907713 <https://reviews.llvm.org/D75390#1907713>, @hctim wrote:
>
> > In D75390#1906642 <https://reviews.llvm.org/D75390#1906642>, @clayborg wrote:
> >
> > > I just need to be able to build my binary with -fsanitize=memory. Most clangs that we have installed do not support this. Is our solution to this really to create your own buildbot and run the test just like the buildbot would? Is there a toolchain I can download from somewhere? This really makes it hard to fix issues that come up.
> >
> >
> > Building the binary with `-fsanitize=memory` is basically it, yes. The tricky thing about MSan is that it requires an-MSan built libcxx/libcxxabi, which which isn't trivial to bootstrap for some configurations, hence I generally just point to the "how to repro exactly the bot". :)
>
>
> It would be great if we maybe built some toolchains to popular targets (linux and Darwin) so people to "sudo yum install clang-msan" or "brew install clang-msan" to allow debugging of these issues.


Yeah... simply adding msan-instrumented libcxx + libcxxabi to the default build of the toolchain and teaching clang driver to detect/link them with msan would solve ~90% of the cases.

>> In D75390#1906732 <https://reviews.llvm.org/D75390#1906732>, @clayborg wrote:
>> 
>>> The full report you attached was enough to see what was going on. Is there a way we can enable always reporting the full output with FileCheck on the msan bots? That would help to see the full report, as we just got the first few lines in the buildbot error message.
>> 
>> 
>> I can take a look at this, but last time I looked into it there was a FileCheck limitation.
> 
> All it would take is to set the default for --dump-input to be "fail" by default for memory sanitizer:
> 
>   --dump-input=fail

This sounds like a very good idea. We'd want this for ASan and other tools that may add interesting information to the binary output, as well.

> After looking at this bug further, I am wondering if the memory sanitizer should have triggered in my case. I had a structure where I didn't init all of the values in one function, and then in another function I wrote a value to this location and this is what triggered the memory sanitizer? Pseudo code:
> 
>   void write32(void *ptr, uint32_t value) {
>      *(uint32_t *)ptr = value; // MSAN triggered here
>   }
>   struct Header = { int a, b; };
>   Header H;
>   H.a = 0;
>   write32(&H.b, 12); 
> 
> 
> And this code caused msan to trigger? I would expect read from uninitialized memory to trigger, but writes?

No, writes should not trigger msan. Unless it's a bitfield (then that would be read-modify-write).
Perhaps ptr or value are *derived* from a something that was read from uninitialized memory?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75390/new/

https://reviews.llvm.org/D75390