- User Since
- Oct 3 2012, 3:00 AM (350 w, 6 d)
Do we need similar protection in deallocate?
Fri, Jun 21
More ideas for tests: multi dimensional arrays, two levels of inlining, lexical scopes.
Please check what happens in "weird" cases with dynamic stack realignment or dynamic sp adjustment. If one or both of these cases can not be handled with this debug info format, can we at least avoid getting confused by them? Are we simply missing fp-offset in the debug info if the offset is not statically known? Add a test case.
I still think my suggestion for the name is best, but don't care about it too much.
Wed, Jun 19
Tue, Jun 18
Mon, Jun 17
remove commented lines
append_list_if(COMPILER_RT_HAS_FPIC_FLAG -fPIC GWP_ASAN_CFLAGS)
Fri, Jun 14
We can make the tags undeterministic again by starting each ring buffer at a random index.
What if we do it the other way around - store SP instead of FP? SP is unusable for locals when there are dynamic allocas; FP is unusable when there is dynamic stack realignment; not sure which case is more common, but both should be rare enough. This could help with the code size at least a little.
Mon, Jun 10
Wed, Jun 5
The instrumentation pass change looks good.
There is a test for fdiv in msan_basic.ll, you can do something similar.
Mon, Jun 3
Tue, May 28
It's a refactoring leftover.
May 21 2019
May 17 2019
May 16 2019
+ IR test
May 15 2019
May 14 2019
I think the idea is that implementing our own spinlock is not much harder than having 3 platform-specific implementations (posix, window, fuchsia).
Also, scudo_standalone is doing the same ( @cryptoad, why? ).
Ha, I think it matches LLVM perfectly :)
G, of course, stands for "Galaxy".
May 13 2019
May 9 2019
May 8 2019
sorry for the delay, I'll take a look later this week
May 3 2019
That's fine, thank you.
I need to submit the change manually anyway.
May 2 2019
add a comment
Should this be an error and cause an "unsupported configuration"?
But we don't really know that, because a change that makes this configuration supported needs to be in libc or in platform build files, not in compiler-rt. I'd rather not block anyone from experimenting.
What about makeing it a warning, "untested configuration"? Obviously your call, just seems prudent to me.
May 1 2019
HWASAN_WITH_INTERCEPTORS=OFF is a mode where we rely on libc to call hwasan_thread_enter and hwasan_thread_exit as appropriate. This is particularly important when libc is built with hwasan, because then instrumented code may run on a thread before GetCurrentThread is called. At this moment, only bionic supports this, as far as I know.
Apr 30 2019
Sorry I've missed your comment. I've uploaded a different fix for __hwasan_tls problem:
Apr 29 2019
disable sanitizer_common reallocarray test on darwin
This change includes D61155.
Looks fine to me. @kcc PTAL
Apr 26 2019
I think __hwasan_tls should be defined if !SANITIZER_ANDROID, without the other condition.
Apr 25 2019
Apr 24 2019
Apr 19 2019
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.
Apr 18 2019
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.
Apr 16 2019
Apr 15 2019
Consider extending the test with another alloca which does not participate in any untraceable lifetimes, but has to be poisoned in entry block anyway.