On Fri, Mar 17, 2023 at 1:31 PM Miguel Ojeda
<miguel.ojeda.sandonis@xxxxxxxxx> wrote:
>
> 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;
Ahh. That explains the odd constants I saw. I did figure out it had
something to do with loading 'mf->code', but then it went off the
rails.
> 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
That code generation is some crazy stuff.
Yeah, that's not acceptable, and the bug is clearly not UBSAN, but
some generic bogus clang thing.
Much nicer to try to debug this as a "objtool complains about the
generated code" rather than as some insane runtine problem with code
falling off the end of the function.
Linus
