Martin Liška <marxin at gcc dot> 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      |marxin at gcc dot

--- Comment #2 from Martin Liška <marxin at gcc dot> ---
(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.

> 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.

Reply via email to