On 19/11/15 13:18, Jakub Jelinek wrote:
On Thu, Nov 19, 2015 at 11:19:23AM +0300, Maxim Ostapenko wrote:
Hi!
Since the last sanitizer library merge to GCC happened, some new useful
features were applied upstream. In particular, the most significant are:
* The shadow offset for ASan was unified on Aarch64 for 39 and 42 VMAs
(http://reviews.llvm.org/D13782). AFAU, this change wouldn't require any
additional support from compiler side, because the shadow offset is the same
as for 39-bit VMA (36) .
* Optional ASan recovery functionality was merged to sanitizer library
(http://reviews.llvm.org/D12318). This feature seems to be very helpful in
complex systems where we may want to proceed to work even in case of bug was
detected. However, to access this functionality, we'll need to implement new
asan_report_{store, load}{1, 2, 4, 8, 16, N}_noabort callbacks in compiler.
This is probably unacceptable for stage 3.
No, those are already there (for -fsanitize{,-recover}=kernel-address).
IMHO all you need is remove:
if (opts->x_flag_sanitize_recover & SANITIZE_USER_ADDRESS)
error_at (loc, "-fsanitize-recover=address is not supported");
in opts.c (finish_options), and in asan.c (asan_expand_check_ifn)
change
bool recover_p
= (flag_sanitize & flag_sanitize_recover & SANITIZE_KERNEL_ADDRESS) != 0;
to say:
bool recover_p;
if (flag_sanitize & SANITIZE_USER_ADDRESS)
recover_p = (flag_sanitize_recover & SANITIZE_USER_ADDRESS) != 0;
else
recover_p = (flag_sanitize_recover & SANITIZE_KERNEL_ADDRESS) != 0;
(plus add some testsuite coverage).
This is small enough change that I'm ok with an exception for this.
I think it would be nice to have unified shadow offset on Aarch64 for 39 and
42 VMAs even in GCC 6 (enabling ASan recovery would be nice too, but it's
much harder).
So, my question is: is it acceptable to backport these features from
upstream without touching compiler side? If so, I see two options here:
- Perform sanitizer library merge to GCC without changing compiler side.
And at this point I also prefer the above, rather than cherry-picking, of
course later on in the process cherry-picking will be desirable instead.
Great, thanks! I'll try to perform another merge as soon as possible.
- Cherry-pick the patch for AArch64 on top of current trunk.
Jakub
