On Fri, Mar 17, 2023 at 7:50 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Debug support *MUST* have an option to just continue. Sure, make "this
> is fatal" be an option *too*, because if you are a developer, maybe
> you really want the "fail hard, fail quickly" behavior.
At least for userspace it has different modes -- the default is to
report and continue:
-fsanitize=...: print a verbose error report and continue
execution (default);
-fno-sanitize-recover=...: print a verbose error report and exit
the program;
-fsanitize-trap=...: execute a trap instruction (doesn’t require
UBSan run-time support).
-fno-sanitize=...: disable any check, e.g., -fno-sanitize=alignment.
(https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#usage)
For the kernel I assume it is meant to work due to `UBSAN_TRAP`, but
the optimizer may be getting in the way.
>From a quick look, it seems that `__find_restype` (which gets inlined
into `m5mols_set_fmt` via `__find_resolution`) has a small loop:
do {
if (code == m5mols_default_ffmt[type].code)
return type;
} while (type++ != SIZE_DEFAULT_FFMT);
that I guess gets simplified into something like:
if (code == first code)
yield 0;
if (code == second code)
yield 1;
out of bounds;
When UBSAN is disabled, it may be assuming:
if (code == first code)
yield 0;
yield 1;
Thus no issue.
Though even with UBSAN disabled, if I add a dummy opaque call inside
the loop, it goes back to something like before, except the jump goes
nowhere and then `objtool` complains again:
.LBB24_20:
callq dummydummydummy
.Lfunc_end24:
So it is reproducible even without UBSAN getting involved:
https://godbolt.org/z/hTe91b3eG
Cheers,
Miguel
