https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94307
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Last reconfirmed| |2020-03-25
Target Milestone|--- |11.0
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Kees Cook from comment #0)
> Instead of unconditionally calling __builtin_trap() for
> -fsanitize-undefined-trap-on-error it would help the Linux kernel's use of
> UBSAN to have a way to specify the trap function. With that, Linux can use
> its own internal exception handling routines and avoid various confused
> states:
Sure, that's definitely possible.
>
> https://lore.kernel.org/linux-next/20200324164433.qusyu5h7ykx3f2bu@treble/
>
> For example something like -fsanitize-undefined-trap-function=__ubsan_trap
> and "__ubsan_trap" can then be defined by the kernel itself. Using the
> standard handler routines (__ubsan_handle_*) are too heavy duty for some
> builds, so a regular trap is needed for the kernel, but this allows us to
> provide a "continue anyway" option as well.
I would rather add something like
-fsanitize-undefined-handler=[runtime,trap,handler] where
- runtime would call current __ubsan_handle_*
- trap would result in ud2
- handler - can be call to __ubsan_trap
Where I can imagine it will call 2 versions (__ubsan_trap and
__ubsan_trap_no_return). That will depend on -fsanitize-recovery=..
I can do a patch for GCC 11.
