[PATCH 01/11] ubsan: Add initial support for -fsanitize=undefined

[DJ Delorie]

Sam James <sam@gentoo.org> writes:
>>> There is no support for the UBSAN_OPTIONS environment variable,
>>> although some options are supported through glibc.ubsan tunables.
>>
>> Suggestion: like gcc does, have each handler support off/warning/error
>> style selection.  I don't think it would be worth it unless it grows
>> beyond the debug stage, though.
>
> Care is required because UBSAN_OPTIONS (as well as the other *_OPTIONS)
> can lead to privilege escalation for suid applications with a custom log
> file.

I was thinking of glibc.ubsan.foo_bar=0/1/2, not UBSAN_OPTIONS.

Should we check for usban and setuid, and just exit with a "don't do
that" ?  Not needed if we don't expect enable-ubsan builds to escape a
development environment.

> Warning is always controversial because the state of the program beyond
> that point is unknown, but maybe it is indeed useful especially during
> initial testing when we expect to find problems in paths exercised by
> applications.

True, but we already have a switch to make them ALL warn/halt.  I was
just suggesting more granularity.

>> I'll ask the usual question: what keeps this default-off code from
>> bit-rotting over time due to lack of use?
>
> In my experience, UBSAN support is usually sought out by certain people
> who will try it every so often (and I'm one of them). I'm not too
> worried about it, especially if we can get to the point where the
> testsuite is clean, and we can recommend people use it when testing
> new patches.
>
> The issue is before we reach that state, but that applies to anything
> incremental...

I'm a big fan of leaving #if DEBUG code in place and unused, for future
needs.  Each time I try, I get asked the above question ;-)