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

[Alexey Samsonov]

On Tue, Jan 29, 2013 at 2:39 PM, Chandler Carruth <chandlerc at google.com>wrote:

> 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.
>

FTR, we do install sanitizer headers when running "make install" in CMake
build tree.
(though, the install path may be adjusted as needed). We may also copy
sanitizer headers
to the build tree if necessary.


>
>
>>
>> > 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
>> >>
>> >
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>


-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130129/c53f4ad2/attachment.html>