[llvm-commits] [PATCH] MemorySanitizer instrumentation pass.

[Evgeniy Stepanov]

On Tue, Oct 30, 2012 at 11:29 AM, Kostya Serebryany <kcc at google.com> wrote:
>
>
> On Tue, Oct 30, 2012 at 11:24 AM, Chandler Carruth <chandlerc at google.com>
> wrote:
>>
>> On Mon, Oct 29, 2012 at 11:28 PM, Kostya Serebryany <kcc at google.com>
>> wrote:
>> >
>> >> > > I don't understand any of this. Why aren't we using trap? Why
>> >> > > aren't
>> >> > > we following the pattern of ASan? What is the goal of UseTrap?
>> >> > Unlike ASan, we want MSan reports to be non-fatal. Normal call spills
>> >> > scratch registers in the caller, etc - it's way too slow (AFAIR, it's
>> >> > ~20%
>> >> > slower than ud2 for very cold calls).
>> >> >
>> >> I would like to understand why cold function calls aren't sunk
>> >> (including
>> >> their spills) out of the flow of the hot path.
>> >>
>> >> Could this be factored so that there is a switch controlling it, and a
>> >> specific function for building a "call" to the warning function? I'm
>> >> not
>> >> thrilled about names like "WarningFn" referring to things other than a
>> >> function. I don't expect this inline asm production to be expensive,
>> >> why not
>> >> just do this as-needed in a helper method? That might make it easier to
>> >> gate
>> >> different behaviors on a flag.
>> >>
>> >> Eventually, I agree that implementing a dedicated calling convention
>> >> that,
>> >> for example, doesn't spill would be really useful to make the IR more
>> >> clear.
>> >> Catching and handling ud2 inline asm is really magical.
>> >>
>> >
>> > I think we can use llvm.trap for now and exit on the first detected bug.
>>
>> Do you mean a no-return call to the runtime function? I think that's
>> what we do in ASan now? Ideally, they would be the same.
>
>
>
> In my experience with msan, no-return call is all we need.
> But Evgeniy used msan on larger apps than I did, let's see what he says.
> If we need any suppressions, no-return call is not a choice.

I have not encountered a situation where msan would need to continue
after error (i.e. suppression mechanism), but I'm pretty sure we will
need it. Just look at Chromium's Valgrind suppression file
http://src.chromium.org/viewvc/chrome/trunk/src/tools/valgrind/memcheck/suppressions.txt?view=markup

ASan reports are pretty reliable - they are always clear errors. TSan
and MSan can be debatable, for example, there are people who believe
in "benign races". Uninitialized data used in a computation may
eventually die out, or just not matter in the end.

>
>
>>
>> > This is the current default mode anyway. Evgeniy, right?
>> > We can later implement the cold calling convention and replace llvm.trap
>> > with cold calls.
>> >
>> >>
>> >> Also, is there any discussion of the rationale behind fatal errors in
>> >> ASan
>> >> and non-fatal here? (similarly for tsan)
>> >
>> >
>> > asan has the best signal vs noise ratio and thus we decided to exit on
>> > first
>> > error. This makes the code smaller/faster.
>> > tsan does all error reporting inside the run-time library, so the
>> > generated
>> > code is not affected by this choice.
>> > msan is still in development and we are not sure if it will have the
>> > same
>> > signal vs noise ratio as asan. Maybe llvm.trap *is* the best choice.
>>
>> I think for simplicity, I'd go with exactly the same behavior as ASan
>> at first. If we find it doesn't work, we should add the flexibility
>> then.
>>
>> >
>> >
>> > --kcc
>> >
>> > _______________________________________________
>> > llvm-commits mailing list
>> > llvm-commits at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> >
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>