Added Marek to comment on proposed UBSan option change.
On 09/18/2014 02:52 PM, Jakub Jelinek wrote:
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1551,6 +1551,12 @@ common_handle_option (struct gcc_options *opts,
| SANITIZE_RETURNS_NONNULL_ATTRIBUTE))
opts->x_flag_delete_null_pointer_checks = 0;
+ /* UBSan and KASan enable recovery by default. */
+ opts->x_flag_sanitize_recover
+ = !!(flag_sanitize & (SANITIZE_UNDEFINED
+ | SANITIZE_UNDEFINED_NONDEFAULT
+ | SANITIZE_KERNEL_ADDRESS));
+
Doesn't this override even user supplied -fsanitize-recover or
-fno-sanitize-recover ? Have you tried both
-fno-sanitize-recover -fsanitize=kernel-address
and
-fsanitize=kernel-address -fno-sanitize-recover
option orders?
I did and this worked in a seemingly logical way:
* -fsanitize=address (disable recovery)
* -fsanitize-recover -fsanitize=address (disable recovery)
* -fsanitize=address -fsanitize-recover (enable recovery)
* -fsanitize=kernel-address (enable recovery)
* -fno-sanitize-recover -fsanitize=kernel-address (enable recovery)
* -fsanitize=kernel-address -fno-sanitize-recover (enable recovery)
Seems for -fdelete-null-pointer-checks we got it wrong too,
IMHO for -fsanitize={null,{,returns-}nonnull-attribute,undefined}
we want to disable it unconditionally, regardless of whether
that option appears on the command line or not.
My understanding is that all
-fsanitize=(address|kernel-address|undefined|you-name-it) are simply
packs of options to enable. User may override any selected option from
the pack if he so desires.
I don't think your proposal will work properly though,
if one compiles with
-fsanitize=undefined -fsanitize=address
you'll just get userland asan with error recovery, which is highly
undesirable
Now that's a problem. Looks like I'll need a separate flag to achieve
what I need (-fasan-recover? And maybe then rename -fsanitize-recover to
-fubsan-recover for consistency?).
or asan.c needs to limit it to flag_sanitize & SANITIZE_KERNEL_ADDRESS
mode only.
We may want to UBsanitize kernel in future and this may cause the same
problem as for userspace Asan/UBSan interaction you described above.
> Depends if you ever want to add recovery for userland
> sanitization.
Also kernel developers want both recoverable (more user-friendly) and
non-recoverable (faster) Asan error handling.
-Y
