<div dir="ltr">On Tue, Jan 29, 2013 at 2:39 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On Tue, Jan 29, 2013 at 2:07 AM, Evgeniy Stepanov <span dir="ltr"><<a href="mailto:eugenis@google.com" target="_blank">eugenis@google.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Tue, Jan 29, 2013 at 2:02 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
> On Tue, Jan 29, 2013 at 1:49 AM, Nick Lewycky <<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>> wrote:<br>
>><br>
>> On 28 January 2013 06:22, Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:<br>
>>><br>
>>><br>
>>> Maybe put this into lib/Support/Valgrind.cpp and/or<br>
>>> include/llvm/Support/Valgrind.h ?<br>
>>> Or maybe rename these files into something Valgrind-neutral?<br>
>><br>
>><br>
>> I'd prefer renaming them to something valgrind-neutral, but I simply can<br>
>> not think of any name. If you can think of something, go for it.<br>
>><br>
>> There needs to be some meaning to this name. For instance Sanitizer.h<br>
>> would work, as it's just as acceptable for sanitizer macros as Valgrind.h is<br>
>> for valgrind macros.<br>
><br>
><br>
> For sanitizer functions, shouldn't the sanitizer ship a builtin header file<br>
> we include to get their declarations?<br>
<br>
</div>Yes, I think we discussed it briefly once. Should we install<br>
sanitizer/*_interface.h headers to lib/clang/$VERSION/include?<br></blockquote><div><br></div></div><div>I think the idea had been to do that, yes.</div></div></div></div></blockquote><div><br></div><div style>FTR, we do install sanitizer headers when running "make install" in CMake build tree.</div>
<div style>(though, the install path may be adjusted as needed). We may also copy sanitizer headers<br></div><div style>to the build tree if necessary.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> For the compatibility macros that wrap these in LLVM's code to remain<br>
> interoperable, I would vote for either Compiler.h, a new Sanitizer.h, or<br>
> MemoryAnnotations.h in order of vaguely decreasing preference.<br>
<br>
</div>Compiler.h does not really capture the spirit of Valgrind annotations.<br>
MemoryAnnotations.h, or maybe DynamicTools.h, or DynamicAnnotations.h?<br></blockquote><div><br></div></div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div>#if LLVM_ENABLE_SANITIZER_ANNOTATIONS</div><div> __msan_annotate_....();</div><div>#endif</div><div><br></div><div>as the user code, Compiler.h providing the enable macro, and the user code including the appropriate header and annotation call.</div>
<div><br></div><div>Then the annotation call itself can be set up to compile away in the absence of the sanitizer...</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
><br>
>><br>
>>> Nick Lewycky (who added Valgrind.*), WDYT?<br>
>>><br>
>>> <a href="http://llvm-reviews.chandlerc.com/D336" target="_blank">http://llvm-reviews.chandlerc.com/D336</a><br>
>>> _______________________________________________<br>
>>> llvm-commits mailing list<br>
>>> <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> llvm-commits mailing list<br>
>> <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
>><br>
><br>
</div></div></blockquote></div></div><br></div></div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div>