- User Since
- Oct 3 2012, 4:55 AM (276 w, 3 d)
Tue, Jan 16
How about this:
A -fsanitize-address-poison-all-array-new or similar (it would be all *except* placement new... Haven't got a better name, though).
That way, a user would be able to poison more array-new operators than the current solution. But we wouldn't break any legal C++ code.
Fri, Jan 12
Technically it is. Just like overriding malloc,
Thu, Jan 11
Let me rephrase the question.
Is the code in new_array_cookie_with_new_from_class.cc a valid C++?
I.e. is the code allowed to access *reinterpret_cast<uintptr_t*>(Foo::allocated) at line 38?
LGTM with two nits, feel free to address them separately.
Wed, Jan 10
The original commit doesn't provide any rationale for this test,
Dec 21 2017
Dec 20 2017
Dec 19 2017
LGTM with a nit
I suggest to restart the discussion of this topic with the owners of fortify.
So far I am not convinced that we need/want this code in asan.
The discussion about asan+fortify has been going on for ages and I don't think we ever reached an agreement on how to proceed. Did we?
Dec 18 2017
Dec 14 2017
Dec 13 2017
Matt, please land
Aleksey, please review.
Please also remove samsonov@ from owners (he is not active in LLVM any more, AFAICT) and replace with yourself.
Dec 12 2017
LGTM with one optional question.
Dec 9 2017
Dec 8 2017
LGTM, let's iterate from here.
My top level comment: can we delete all non-aarch64 code?
The arch owners can reinstate it if needed, but they will only need it if/when they have the TBI feature in HW.
Dec 7 2017
LGTM, please wait for (at least) Aleksey's review.
Common code LGTM
Dec 6 2017
please give at least Aleksey a chance to review as well.
Please document the new attribute and explain why the old attribute doesn't work for us (there are cases when we need one, but not the other, in both directions)
Too many #ifdefs in the code -- we can not let this in.
Please find a way to reduce (to ~ zero) the number of #ifdefs inside the code.
Prefer to have solaris-specific functionality in separate files.
Dec 5 2017
Will https://reviews.llvm.org/D37631 help?
Dec 4 2017
Dec 1 2017
This change introduces more ifdefs to this file, which is bad.
It already has one ifdef -- and that one is already for "defined(_MIPS_SIM)"
Please don't introduce any more ifdefs, instead please add a new file (something_something_mips.h) and remove the only ifdef from here.
Nov 30 2017
Rename the new tool to HWASAN
Will this even build on Linux?
I don't see MADV_FREE in /usr/include
Nov 29 2017
could you please also add a lit test that uses -stdlib=libc++?
Matt, please also take a look.
rephrase the sources of asan overhead
Nov 28 2017
mention alternatives for memory access instrumentation
Do you need an LLVM cmake rule for that?
kongyi , what exactly are you trying to achieve?
minor edit (explained shadow)
Do you need us to land it?
If so, Matt will do it.
Nov 27 2017
- I see two independent changes here. If so, please split them into two patches
- most changes need tests.
- Maybe instead of doing this, introduce some logic to treat log_path=/dev/null as a special supported case?
Nov 26 2017
Why do you think this is a bug?
The user-provided counter is a counter, not a bit set.
Nov 16 2017
Nice, thank you!
Do I understand correctly that this is a no-functional-change-intended change?