Introduce the -f[no-]address-sanitizer-dynamic-runtime option

Hi,

the attached patch (see also Issue 6483051: Introduce the -f[no-]address-sanitizer-dynamic-runtime flag - Code Review)
adds the -faddress-sanitizer-dynamic-runtime command line option to
Clang.
If set, this option causes the linker to use the runtime library built
as .dylib on Mac OS

asan-dynamic.patch (2.32 KB)

Hi Alex,

I don't really see why we need a separate flag from -faddress-sanitizer. On OS X, our only real long-term solution is to use the dynamic runtime. While it's a great hack, the mach_override solution is just not a viable solution for the OS X security model. At least with the dylib solution, we're far more likely to get it to work with OS X sandboxing.

I'm fine with having a separate flag for the purpose of staging implementations, but I don't see value in having users having to know about -faddress-sanitizer and -faddress-sanitizer-dynamic-runtime, and I don't see a reason why users would want to disable using the .dylib solution on OS X.

What do you think?
Ted

Hi Alex,

I don't really see why we need a separate flag from -faddress-sanitizer. On OS X, our only real long-term solution is to use the dynamic runtime. While it's a great hack, the mach_override solution is just not a viable solution for the OS X security model. At least with the dylib solution, we're far more likely to get it to work with OS X sandboxing.

You are right, but we'd like to keep mach_override until it's possible
to run something heavy (e.g. Chromium) under both versions and make
sure everything is fine.
In fact adding a separate flag for the dynamic runtime isn't really
needed for this -- we can live with -lclang_rt.asan_osx_dynamic
instead.

You are right, but we’d like to keep mach_override until it’s possible
to run something heavy (e.g. Chromium) under both versions and make
sure everything is fine.

Right, makes sense. That’s what I meant by “staging implementations.”

In fact adding a separate flag for the dynamic runtime isn’t really
needed for this – we can live with -lclang_rt.asan_osx_dynamic
instead.

Ultimately, if we bundle the dylib with the compiler, I would expect that “-faddress-sanitizer”, when passed to clang for linking a framework/executable, would automatically imply -lclang_rt.asan_osx_dynamic. I’d rather that build systems or users didn’t need to know about such esoteric details, and passing “-faddress-sanitizer” to clang for linking does “the right thing”.

Ok, let us not introduce extra flags.
I'll keep the current behavior of -faddress-sanitizer, and if someone
wants to use the dynamic runtime until it's officially supported he
can use -lclang_rt.asan_osx_dynamic instead of -faddress-sanitizer.
Once we make sure everything works fine, -faddress-sanitizer will link
with the dynamic runtime by default.