[llvm-commits] [PATCH] Annotate BumpPtrAllocator for MemorySanitizer

[Chandler Carruth]

On Tue, Jan 29, 2013 at 2:07 AM, Evgeniy Stepanov <eugenis at google.com>wrote:

> On Tue, Jan 29, 2013 at 2:02 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> > On Tue, Jan 29, 2013 at 1:49 AM, Nick Lewycky <nlewycky at google.com>
> wrote:
> >>
> >> On 28 January 2013 06:22, Kostya Serebryany <kcc at google.com> wrote:
> >>>
> >>>
> >>>   Maybe put this into lib/Support/Valgrind.cpp and/or
> >>> include/llvm/Support/Valgrind.h ?
> >>>   Or maybe rename these files into something Valgrind-neutral?
> >>
> >>
> >> I'd prefer renaming them to something valgrind-neutral, but I simply can
> >> not think of any name. If you can think of something, go for it.
> >>
> >> There needs to be some meaning to this name. For instance Sanitizer.h
> >> would work, as it's just as acceptable for sanitizer macros as
> Valgrind.h is
> >> for valgrind macros.
> >
> >
> > For sanitizer functions, shouldn't the sanitizer ship a builtin header
> file
> > we include to get their declarations?
>
> Yes, I think we discussed it briefly once. Should we install
> sanitizer/*_interface.h headers to lib/clang/$VERSION/include?
>

I think the idea had been to do that, yes.


>
> > For the compatibility macros that wrap these in LLVM's code to remain
> > interoperable, I would vote for either Compiler.h, a new Sanitizer.h, or
> > MemoryAnnotations.h in order of vaguely decreasing preference.
>
> Compiler.h does not really capture the spirit of Valgrind annotations.
> MemoryAnnotations.h, or maybe DynamicTools.h, or DynamicAnnotations.h?
>

On further consideration, I'd like to hoist more of this up into the
interface header provided by the sanitizer. Essentially, there is no reason
it can't bundle all of the logic about making the annotation a no-op when
the particular sanitizer is disabled, etc.

That really reduces the necessary magic to providing a hook to disable the
header itself when not compiled with a suitably recent Clang. That's why I
had wondered about Compiler.h. We might end up with:

#if LLVM_ENABLE_SANITIZER_ANNOTATIONS
  __msan_annotate_....();
#endif

as the user code, Compiler.h providing the enable macro, and the user code
including the appropriate header and annotation call.

Then the annotation call itself can be set up to compile away in the
absence of the sanitizer...


>
> >
> >>
> >>>   Nick Lewycky (who added Valgrind.*), WDYT?
> >>>
> >>> http://llvm-reviews.chandlerc.com/D336
> >>> _______________________________________________
> >>> 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
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130129/afa0e681/attachment.html>