On Wed, May 17, 2023 at 12:16 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > On Wed, May 17, 2023 at 12:09:35PM -0700, Fangrui Song wrote: > > On Wed, May 17, 2023 at 12:08 PM Fangrui Song <maskray@xxxxxxxxxx> wrote: > > > > > > On Wed, May 17, 2023 at 12:02 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > > > > > > > On Fri, 7 Apr 2023 14:54:06 -0700, Nick Desaulniers wrote: > > > > > -fsanitize-undefined-trap-on-error has been supported since GCC 5.1 and > > > > > Clang 3.2. The minimum supported version of these according to > > > > > Documentation/process/changes.rst is 5.1 and 11.0.0 respectively. Drop > > > > > this cc-option check. > > > > > > > > > > > > > > > > > > Applied to for-next/hardening, thanks! > > > > > > > > [1/1] ubsan: remove cc-option test for UBSAN_TRAP > > > > https://git.kernel.org/kees/c/08e4044243a6 > > > > > > > > -- > > > > Kees Cook > > > > > > > > > > > > > > For this -fsanitize-undefined-trap-on-error, I think we need a v2 patch that > > > tries -fsanitize-trap=all as well. > > > > Correction: -fsanitize-trap=undefined > > > > > -fsanitize-undefined-trap-on-error has been deprecated in Clang for 8 > > > years, and at some point we will remove the option. > > > > > > GCC implements -fsanitize-trap=all later, but > > > -fsanitize-undefined-trap-on-error is documented as deprecated as > > > well. > > Right now all the compilers support the old way, and I'd rather remove a > cc-option call than add two. :) > > -- > Kees Cook Hmm, this gives Clang developers a disadvantage... Anyone who removes Clang's -fsanitize-undefined-trap-on-error (or give it a warning before removal) will probably face complaints from kernel developers... -- 宋方睿
