May 15 2018
Apr 25 2018
Apr 12 2018
Feb 12 2018
Feb 8 2018
Update commit message.
I don't understand why your description of this patch mentions the void* placement new operator. There's no cookie to poison for that operator.
Feb 7 2018
I've posted D43013 to add the flag + behaviour to clang.
Thanks for pointing out the issues,
Jan 15 2018
Technically it is. Just like overriding malloc,
That's a weak analogy. You can't override malloc and still use asan with it.
Derp, I forgot the open source version doesn't allow this. No problem.
Jan 12 2018
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?
Technically it is. Just like overriding malloc, saving a pointer to every block, and occasionally reading from those pointers. Both these cases will trigger ASan errors on array cookies (the malloc one will trigger it even without my patch, not on this example, but in other, simpler, ones).
Jan 11 2018
BTW, the code around D41301 seem to have always been that way. Which made me unsure if this was a case of "only this got implemented and we never got around to adding the other cases", or if there was an actual problem somewhere.
I have small tests on my side, but since it's really only about codegen, I haven't pushed a compiler-rt test (there was no bug to be fixed on compiler-rt's side).
I can change this test to remove that dependency instead of removing it, though.
Jan 8 2018
Jan 2 2018
Dec 15 2017
Dec 8 2017
Nov 10 2017
Seems ok assuming that construct is safe.
Nov 8 2017
Nov 6 2017
Looks good. I’ll ask you to wait a bit and see if @pcc has any objection, though.
Oct 26 2017
What's the meaning of (old) "norename" in thin LTO? I couldn't track it down, but it seems like it might be helpful. If it's to tell whomever imports the module that that function can't be renamed, then I think dllexported functions should be tagged as such.
I can see a case for allowing an importing module to inline dllexport functions without allowing it to delete the original, though. I'm not sure if norename (now NotEligibleToImport) allows this.
It looks like this will only work for full LTO, and not ThinLTO.
How does your linker decide which symbols are exported from regular object files? Should there instead be a mechanism to get that information from the lto::InputFile?
Oct 25 2017
Oct 17 2017
Oct 16 2017
Thanks for the patch, but it seems to be trying to paper over another problem instead of fixing it.
I've commented on the specific line where I have concerns.
Oct 2 2017
Sep 29 2017
Sep 28 2017
Add umbrella-header-include-builtin.mm too
Sep 25 2017
- Break from the inner loop after we successfully merge (kill) the earlier and later stores.
- Add test reduced from PR34074 that was crashing.
Aug 4 2017
Jul 31 2017
Update for newer SynchScope API.
@sanjoy: Any thoughts?
LGTM. You might want to remove this from the commit message, though:
Jul 28 2017
Looks good in general, but can't comment much on the OS itself :-)
I have a few changes I'd like to see, though.
Jul 20 2017
Jul 19 2017
Should we simply not have ubsan_blacklist.txt if it's empty?
Ugh, implicit truncate/extend strikes again. I keep forgetting about those.
LGTM, I'm ok with the choice in the use of MatchShiftTooBig, but maybe add a tiny comment mentioning you picked the safer option?
This should be merged with the FreeBSD one. The differences are minor and it looks like you can cover all of them with two or three simple conditional operators or ifs.
Jul 18 2017
Can you rebase this patch, please? Preferably after applying the previous patches that have been accepted.
Jul 13 2017
At the very least: This is adding a ton of unused and unneeded details. If we end up needing to dispatch on processor family, then maybe we can add (some of) these.
Otherwise, I don't think it's reasonable to add all these enum values.
Jul 12 2017
Sorry I don't have much to comment yet, but I have some nitpicky comments + (very) small improvement on diff size.
I don't get what you want to do here, sorry.
As I see it, in all the uses of propagateIRFlagsWithOp(X, Y, Z), we have Z == Y. Which will end up being *almost* the same as the propagateIRFlags but with the side-effect that Z will also have those flags.
I'm not sure if Z having those flags is on purpose, though. And I don't see what we get from that.
I haven't reviewed the usages of propagateIRFlagsWithOp, but this really needs test cases. Please add them.
Jul 10 2017
With recent changes to NetBSD-current, all tests pass.Testing Time: 5.35s Expected Passes : 261
Hi @sanjoy. Can you take a look at the revised changes?
Jul 7 2017
Can you split interception and sanitizer_common from ubsan patches?
I'd also rather have the sanitizer_common stuff + ninja check-sanitizer working before enabling UBSan, since it'd be easy to split those changes.
I'd also split the interception patches from sanitizer_common unless there's a problem running the tests with only one of those.
When you enable UBSan you might also be able to enable CXX_ABI on NetBSD, assuming it uses the usual Itanium C++abi.
Jul 6 2017
Jun 30 2017
Address Sanjoy's review comments
Jun 26 2017
I hope I've cleared this up, but: we need to store the source location constant _somewhere_, before we emit the return value check. That's because we can't infer which return location to use at compile time.
Yes, sorry about that. I was thinking about the code the wrong way around. I'm ok with this patch and how it got in. Sorry for the delay in replying.
Jun 22 2017
The source locations aren't constants. The ubsan runtime uses a bit inside of source location structures as a flag. When an issue is diagnosed at a particular source location, that bit is atomically set. This is how ubsan implements issue deduplication.
It's still an llvm::Constant. Just like in StaticData, in line 2966.
Basically, I don't see why we need to add the store/load and an additional indirection, since the pointer is constant, and we can just emit the static data as before.
We're already doing Data->Loc.acquire(); for the current version (and all the other checks).
Splitting the attrloc from the useloc might make sense since we would be able to emit attrloc just once. But I don't see why we need to store/load those pointers in runtime instead of just caching the Constant* in CodeGenFunction.
I'd also like to have some asserts and explicit resets to nullptr after use on the ReturnLocation variable, if possible.
Jun 14 2017
Jun 7 2017
Jun 5 2017
LGTM with a minor comment nit (if I'm right).
Code expansion is annoying, but it becomes closer to source semantics.
Jun 1 2017
@sanjoy: Are you ok with the changes I made?
May 31 2017
Should we add TODO comments to all those overrides and state that the errors should be fixed and the overrides (and the function itself, afterwards) be removed?
May 26 2017
I usually do not work with clang. Do you have instructions I can follow to get that bc file ?
As for performance (I assume you meant compile time performance impact) here are the time I get for a test suite run:
Without this patch:real 2m41.665s user 26m33.900s sys 2m44.728s
With this patch:real 2m42.729s user 26m45.772s sys 2m42.796s
It doesn't looks like the impact is that significant and it seems worth it to me.
May 18 2017
May 17 2017
May 15 2017
Address Sanjoy's comment and add Synchscope and atomic settings from the original store.
May 10 2017
I'd put that namespace inside llvm too.