- User Since
- Jan 22 2018, 10:31 AM (182 w, 6 d)
Jun 12 2020
May 29 2020
The change looks good to me.
Oct 11 2019
Apr 13 2018
Apr 12 2018
Fixed the assert. PTAL.
Apr 10 2018
Hm, I don't see this failure. Just in case I rebased onto the latest tip.
Apr 9 2018
Thanks! Could you commit this?
Thanks! Could you commit this as well?
Apr 6 2018
Added a test.
PTAL. Added AlwaysRecoverable to SanitizerArgs.cpp. Right now recovery is disallowed for both KASan and KHWASan, but all the appropriate flags seem to be passed properly to the instrumentation pass, so we can easily allow it in the future in we want.
Also rebased onto the latest tip.
I don't have any preference between -fsanitize=kernel-address and -fsanitize=address -mllvm asan-kernel=1. GCC uses -fsanitize=kernel-address and I think it looked quite logical to use the same in Clang.
Apr 4 2018
Could you commit this?
The -fsanitize=kernel-address flag is used by the kernel and we should leave it. The no_sanitize("kernel-address") attribute is not used in the kernel, so it's totally OK to get rid of it. What kind of changes would that require? AFAIU clang/include/clang/Basic/Sanitizers.def is used to generate both, the flag and the no_sanitize attribute.
Apr 3 2018
Addressed @eugenis comments.
I don't see an easy way to fix this in SemaDeclAttr.cpp. The way that I see is to change std::vector<StringRef> Sanitizers to something like std::set, then .insert("kernel-address") when we see "address" and vice versa, and then convert back to vector before passing to D->addAttr. What do you think?
Mar 29 2018
Rebased onto https://reviews.llvm.org/D44699
I think it makes sense to make both no_sanitize("address") and no_sanitize("kernel-address") work. Done that.
Mar 28 2018
Mar 27 2018
What do you mean by "(0 .. 0xFF, -1)"? Should it accept a list of tag values in some format?
Mar 23 2018
Feb 21 2018
If to land means to commit, then yes, please :)
Try harder to install SIGTRAP handler.
Install SIGTRAP handler.
Use 0x900 instead of 0x100 for brk immediate (0x100 - 0x800 are unavailable in the kernel).
It seems that hwasan_linux.cc is in a different repo (compiler-rt) and is not picked up by svn diff. Do I need to submit that change as a separate patch?
This is still not committed AFAICT.
Renamed kernel_inline.ll to kernel-inline.ll
Switched user space hwasan to brk.
Fixed and added tests.
Feb 9 2018
Feb 7 2018
I'll send my patch with more khwasan related changes, once this is committed.
Feb 6 2018
Jan 26 2018
Sorry, it was supposed to go on top of https://reviews.llvm.org/D42423 (which is committed now).
Anyway, I noticed an issue in naming ("loadN" is actually supposed to be "load_n") and another issue with asan flags (need "-asan-recover=1" and "noabort" suffixes).
Could you try again?
Fixed "_n" vs "N" naming and added "-asan-recover=1" flag, which is always enabled for the kernel.
Jan 25 2018
Could you commit this?
Yes, that would be great if you commit this.
Jan 24 2018
Jan 23 2018
It is strange indeed.
Asan uses "asan_loadN" and "asan_storeN" and hwasan now has "hwasan_loadN" and "hwasan_storeN", so both use "N" and this is consistent as is.