- User Since
- Oct 3 2012, 3:00 AM (333 w, 9 h)
Fri, Feb 15
Thu, Feb 14
Wed, Feb 13
revert unrelated changes
added an empty line
Tue, Feb 12
+ a comment in test
Thu, Feb 7
Wed, Feb 6
Looks good enough to me.
I've re-read the original problem. Since this is not custom cflags, but an LLVM cmake flag, I think we are obligated to handle it.
Removing -stdlib.* from the flags looks like an OK solution.
We could also fix clang to understand that in "-stdlib=libc++ -nodefaultlibs" there are no unused flags, like with the other flag groups that cancel each other.
Tue, Feb 5
Btw, I've pushed the RSS utility here:
It depends on this change to find the shadow region. It is hwasan-specific, but can be easily adapted to other sanitizers if needed.
It's also really ugly, but I don't want to invest time in beautifying it.
Does the problem appear when -stdlib is passed through custom CFLAGS? I think it is common to disable WERROR as well in that case, or add -Wno-unused-command-line-argument to custom CFLAGS.
Mon, Feb 4
I find the current code more readable than with this change.
Thu, Jan 31
Do we have a test that at most one __asan_handle_no_return call is inserted before a [[noreturn]] call?
Doing less things while libc is not fully initialized is a step in the right direction.
Tue, Jan 29
LGTM assuming the plan is to add !nosanitize where !noreturn has been, at the original call site, in the follow-up change.
Mon, Jan 28
Since the previous iteration of this was controversial, please wait for at least one more review.
Thu, Jan 24
Maybe the frontend should insert __asan_handle_noreturn whenever ASan is enabled, and then ASan would not care about the attribute? I'd like to avoid having this logic in two places.
Wouldn’t it be preferable to unpoison the stack inside of maybe_longjmp, once the opaque condition can be checked?
Because "expect_noreturn" calls are allowed to return, the compiler must behave as they could. In particular, this means that unpoisoning the stack before expect_noreturn calls (given the current semantics) is premature.
Wed, Jan 23
That should not be necessary.
__asan_handle_noreturn is needed for functions that move SP without going through ASan epilogue, in order to maintain the requirement that stack below SP has clean shadow.
Ubsan-rt does nothing of the sort.
madvise the entire allocation range
This patch is missing tests for the new attribute in AsmParser / BitcodeReader / BitcodeWriter.
Tue, Jan 22
I think I could, but it would make the tests (more) painful to update. I guess I could drop the tests for abort in basic.ll in the first change and then bring them back in the second change, if that's ok?
More than half of this changelist is switching shadow addressing to getelementptr. Could you do it in a separate change?
Jan 18 2019
This one is hard to test reliably for RSS change, because it only affect thread exit, and, generally, we don't know how much memory the platform thread support would release in that event, and it might even be a different amount for different threads (some kind of stack caching, etc).
a test case
LGTM with comments.
Jan 17 2019