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

[Mark Wielaard]

Hi Evgeny,

On Sun, 2021-12-05 at 19:52 +0300, Evgeny Vereshchagin wrote:
> > See how I used it to workaround isssues with the
> > gcc address sanitizer. You can use it likewise to work around
> > issues
> > with clang. e.g. the configure check should detect the issue with
> > --no-undefined and could try if adding -lasan to LDFLAGS helps
> 
> I saw that patch and I think it should make building elfutils with
> gcc and running the unit tests under ASan easier. Thanks! But it's
> based on the assumption that configure controls ASan flags and can
> change CFLAGS/LDFLAGS however it needs. Unfortunately I can't do that
> on OSS-Fuzz because all the sanitizer options are passed via CFLAGS
> there and I can't interfere with those CFLAGS.

But that doesn't really work if you use clang. It would actually work
as is if you used gcc. But I am not sure trying to use arbitrary
sanitizer flags that aren't tested in the upstream project is a good
idea.

I am not against OSS-Fuzz. I have had good experiences with using
fuzzers on the elfutils code base. But I find the project slightly
annoying. It requires a github and a google account and it hides the
results from the upstream project. 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).
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 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.

> >  Do you
> > know why these issues are flagged? Are there any extra ASAN_OPTIONS
> > set in these cases?
> 
> No, there aren't. Those issues are flagged because
> -fsanitize=undefined in clang by default includes "pointer-overflow"
> and "vla-bound" (which as far as I know aren't available in gcc)

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

Cheers,

Mark