r198858 - Disable LeakSanitizer in TableGen binaries, see PR18325

[Alp Toker]

On 09/01/2014 17:52, Jordan Rose wrote:
>
> On Jan 9, 2014, at 9:42 , Alp Toker <alp at nuanti.com 
> <mailto:alp at nuanti.com>> wrote:
>
>>
>> On 09/01/2014 17:30, Jordan Rose wrote:
>>>
>>> Would it help if the function were pre-declared in a system header, 
>>> and then just implemented or not implemented in user code?
>>
>> Hi Jordan,
>>
>> That's the current situation -- as long as sanitizer headers are 
>> available and in use the part of the spec you highlighted means it's 
>> acceptable.
>>
>> The problem arises when sanitizer headers aren't available.
>
> I just don't think the program is illegal when LEAK_SANITIZER is not 
> defined. The tokens within the #ifdef are skipped completely, so they 
> don't refer to names and certainly don't declare anything.


If there was an ifdef in TableGen there'd be no problem. The trouble is 
there is no ifdef...

utils/TableGen/TableGen.cpp:

    |int main(int argc, char **argv) {|||
    |||  sys::PrintStackTraceOnErrorSignal();|||
    |||  PrettyStackTraceProgram X(argc, argv);|||
    |||  cl::ParseCommandLineOptions(argc, argv);|||
    ||||
    |||  return TableGenMain(argv[0], &LLVMTableGenMain);|||
    |||}|||
    ||||
    |||extern "C" {|||
    |||// Disable LeakSanitizer for this binary as it has too many leaks
    that are not|||
    |||// very interesting to fix. __lsan_is_turned_off is explained in|||
    |||// compiler-rt/include/sanitizer/lsan_interface.h|||
    |||*int __lsan_is_turned_off() { return 1; }*|||
    |||}  // extern "C"|


Kostya said he preferred not to conditionalize the definition, but 
provide it unconditionally.

That's why I've been trying to help find a name that can be legitimately 
defined in ordinary builds.

If that's no longer a requirement, I'm absolutely fine to guard it with 
ifdef LEAK_SANITIZER and be done with it.

(If that ends up being the resolution, it's a little unfortunate for 
compiler-rt because a well-chosen name would have solved the problem for 
all projects. Either approach is acceptable though in terms of a 
resolution though from my POV.)

Alp.


>
> I'm not sure we should care about the case where LEAK_SANITIZER is 
> defined in an environment that doesn't specify what defining this 
> particular name will do. The user has full control over this. (And in 
> fact, IIRC being able to define macros on the command line isn't at 
> all specified by the standard, so the program by itself will 
> /always/ skip the LEAK_SANITIZER block.)
>
> Jordan
>

-- 
http://www.nuanti.com
the browser experts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140109/d14965f6/attachment.html>