- User Since
- Oct 3 2012, 3:00 AM (341 w, 2 d)
IMHO, we could use printf() in gwpasan directly, with a guard against recursive malloc.
I don't think this will work in a signal-safe manner. The only times that GwpAsan calls printf() is in the signal handler, and even if we temporarily disable sampled allocations, we still are exercising non-reentrant functions in a signal handler.
Thu, Apr 18
If the atomic load ends up on the hot path, we could try moving it to the same cache line as NextSampleCounter. That would make it thread local, but it can be initialized from the global variable on the slow path.
Tue, Apr 16
Mon, Apr 15
Consider extending the test with another alloca which does not participate in any untraceable lifetimes, but has to be poisoned in entry block anyway.
Fri, Apr 12
Please test the case when alloca can not be found.
See https://bugs.llvm.org/show_bug.cgi?id=41481 for the reference.
This is very similar to GetUnderlyingObject, but it also handles PHIs, has a cache, but does not do InstructionSimplify and does not have a lookup limit.
It would be nice to merge the two.
Thu, Apr 11
Is this meant as a test-only thing?
I don't think we want sanitizer Printf anywhere close to production.
Mon, Apr 8
Thu, Apr 4
Yes, seems pretty obvious.
Wed, Apr 3
I think I prefer the cmake flag, too.
It's not unthinkable that hwasan might stop providing operator new and friends in the future. I was a bit surprised that we even do it now in COMPILER_RT_HWASAN_WITH_INTERCEPTORS=OFF configuration - but it looks like we are keeping it.
Anyway, lets not hardcode this decision.
Wed, Mar 27
Tue, Mar 26
To see this problem, move your build directory to a full path starting with "/c".
Mar 14 2019
As far as I can see, "unit" tests in lib/msan/tests also use the freshly built compiler through msan_compile / clang_compile cmake macros. Otherwise this CL would break everyone's builds.
Mar 12 2019
Reverted in r356001.
Mar 11 2019
This is expected to break. I'm surprised it did not break earlier - we often do a compiler change and corresponding integration tests in compiler-rt as a single commit, or two consecutive commits.
Mar 8 2019
Could this be done with a target("sse4.2") function attribute instead of cmake conditions?
LGTM, good job!
Mar 5 2019
you have a test file under lib/Target/AArch64.
Is it intentional? I don't think it does anything...
Mar 4 2019
This needs a compiler-rt test.
Mar 1 2019
Feb 28 2019
Feb 27 2019
And D58755 to make sure this never happens again.
r355064 should do this.
Thanks, I'll fix it in a moment.
This bot seems unhappy: