[PATCH v3] build: allow turning off --no-undefined and -z,defs

[Evgeny Vereshchagin]

Hi Mark,

> But that doesn't really work if you use clang.

It kind of does because almost everybody who builds their projects with clang sanitizers
turns off `z,defs` and `--no-undefined`. I agree it looks weird (and it's probably weird) but
it's just how it has been done for I don't know how many years. My understanding is
that it will never be fixed mostly because unlike gcc, clang doesn't support "shared" ASan/UBSan/MSan
(or, more precisely it isn't actively maintained there and it isn't used in general).

> sanitizer flags that aren't tested in the upstream project is a good
> idea.
> 

I wouldn't say that they are arbitrary. They have been tested with about 400 projects I think
and new flags are rolled out only if they don't break anything.

> It requires a github and a google account and it hides the
> results from the upstream project.

I don't think github accounts are required there but to due to some limitations gmail accounts
have to be used unfortunately. There is a flag there I can flip to prevent OSS-Fuzz from
restricting bug reports in the first place but I think I wrote it elsewhere already (after this email was sent)
and it'd probably make sense to keep discussing it there.

> Also the way they setup the fuzzers
> feels odd (like how they try to cram everything through the CFLAGS and
> how they try to link against a C++ library even for plain C projects).

They have to support a lot of different build systems there and I think it was decided that
CFLAGS is the only thing that they can use to affect them (which I think makes sense).
clang++ and stlibc++ have something to do with UBSan as far as I know.

> I really would like to have any fuzzing targets be part of the upstream
> project so we can all run the fuzzers instead of having to rely of
> Google.

I'm planning to move the fuzz targets upstream eventually and include them in the test suite
at least but I think they should be
compatible with OSS-Fuzz either way (because it's kind of hard to set up continuous
fuzzing manually)

>> I agree that it would be great to make `--enable-sanitize-
>> {undefined,address}` work with clang as well but I think it can be
>> done later on top of `--disable-undefined`.
> 
> I think it should be done as part of --enable-sanitize-address.

If --enable-sanitize-address controlled it, I'm not sure how I would build elfutils with Memory Sanitizer
(where I have to turn z,defs and no-undefined as well).

> But those seem to report bogus issues. At least in these cases, it
> seems the code is fine.

The rationale behind those checks (and why they are enabled by default) can be found
at https://reviews.llvm.org/D67122. My understanding is that code with that kind of UB
is known to be miscompiled from time to time.

Thanks,
Evgeny Vereshchagin