On 09/01/2014 12:03, Chandler Carruth wrote:
On Thu, Jan 9, 2014 at 4:01 AM, Kostya Serebryany <[email protected]
<mailto:[email protected]>> wrote:
On Thu, Jan 9, 2014 at 3:57 PM, Chandler Carruth
<[email protected] <mailto:[email protected]>> wrote:
On Thu, Jan 9, 2014 at 3:50 AM, Kostya Serebryany
<[email protected] <mailto:[email protected]>> wrote:
We currently don't have any macro that is used to enable
lsan in llvm bootstrap.
We can easily add one, no problem, and then put this code
under #ifdef LEAK_SANITIZER
It would make things a bit more ugly.
We have tow problems to solve wrt lsan and bootstrap:
1. Make asan+lsan bootstrap clean. This is what I need to
solve now to enable leak checking for the entire llvm. For
this we may also use #if __has_feature(address_sanitizer).
2. Make any+lsan bootstrap clean ("any" is one of asan,
tsan, msan, <none>). This may introduce more complexity
and that is why the current solution is nice. I don't have
to solve this general problem though for the asan+lsan
bootstrap bot.
I would have some macro (or __has_feature) which is enabled by
any flagset that links the lsan runtime library.
That's not trivial because lsan could be used as a link-time-only
feature (or even as LD_PRELOAD-ed library),
so there is not way to distinguish at compile time if lsan will be
present.
I understand that, but the question is -- do you think that usage
pattern will be prevalent? Is it worth putting an external definition
in the binary *always* just to catch the case where we do a
link-time-only flag?
Put another way, is it really too burdensome to say that LSan does
require a compile time flag in order to support some usage patterns?
Who controls / defines the interface?
This looks like a spectacular thinko rather than being something
intentional -- is it possible to fix it to drop one or more underscores
instead of devising workarounds?
There's never a valid reason to require user code to define reserved
names (although it's sometimes OK for user code to _use_ reserved names).
I'm heading out for a couple of hours, please gate this behind a macro
or revert until a resolution is found.
Thanks
Alp.
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
