Re: [Libjit] Miscompilation problem

[Aleksey Demakov]

Thanks for the report, I will look into this on the weekend.

On Mon, Jan 8, 2018 at 4:39 PM, David Meyer <address@hidden> wrote:
> I’ve been encountering this sporadically for several weeks. I finally have
> an isolated example (attached, minimal.c). It will attempt to reproduce the
> miscompilation. There is some trial and error involved, since it requires
> triggering an out-of-memory compile restart at just the right time. When it
> detects a miscompile, it dumps the corresponding object code to
> /tmp/minimal.dump. Here is what it looks like when it miscompiles:
>
>     7ffff7fb402f:       55                      push   %rbp
>
>     7ffff7fb4030:       48 8b ec                mov    %rsp,%rbp
>
>     7ffff7fb4033:       48 83 ec 30             sub    $0x30,%rsp
>
>     7ffff7fb4037:       4c 89 34 24             mov    %r14,(%rsp)
>
>     7ffff7fb403b:       4c 89 7c 24 08          mov    %r15,0x8(%rsp)
>
>     7ffff7fb4040:       4c 8b f7                mov    %rdi,%r14
>
>     7ffff7fb4043:       89 75 f8                mov    %esi,-0x8(%rbp)
>
>     7ffff7fb4046:       89 55 f0                mov    %edx,-0x10(%rbp)
>
>     7ffff7fb4049:       e9 78 78 00 00          jmpq   0x7ffff7fbb8c6
>
>     7ffff7fb404e:       44 8b 7d e8             mov    -0x18(%rbp),%r15d
> <<<<<<<<<<
>
>     7ffff7fb4052:       41 83 c7 00             add    $0x0,%r15d
>
>     7ffff7fb4056:       e9 7b 78 00 00          jmpq   0x7ffff7fbb8d6
>
>
>                ... large dummy jumptable section...
>
>
>     7ffff7fbb8c6:       45 8b fe                mov    %r14d,%r15d
>
>     7ffff7fbb8c9:       44 03 7d f8             add    -0x8(%rbp),%r15d
>
>     7ffff7fbb8cd:       44 03 7d f0             add    -0x10(%rbp),%r15d
>
>     7ffff7fbb8d1:       e9 78 87 ff ff          jmpq   0x7ffff7fb404e
>
>     7ffff7fbb8d6:       41 83 fe 64             cmp    $0x64,%r14d
>
>     7ffff7fbb8da:       0f 84 7b 87 ff ff       je     0x7ffff7fb405b
>
>     7ffff7fbb8e0:       41 8b c7                mov    %r15d,%eax
>
>     7ffff7fbb8e3:       4c 8b 34 24             mov    (%rsp),%r14
>
>     7ffff7fbb8e7:       4c 8b 7c 24 08          mov    0x8(%rsp),%r15
>
>     7ffff7fbb8ec:       48 8b e5                mov    %rbp,%rsp
>
>     7ffff7fbb8ef:       5d                      pop    %rbp
>
>     7ffff7fbb8f0:       c3                      retq
>
>
>
>
> The code at the top of the function is confused about where the value “v”
> (defined on line 44 of minimal.c) lives. The code at the bottom assumes that
> the value lives in register %r15, but the code at the top pulls it from the
> stack at -0x18(%rbp), even through it is never written there.
>
> I have only a vague idea of what might be happening. The value “v” is bound
> to a global register by codegen_prepare() (which runs on the first compile,
> but not after restarts). The memory exception triggers reset_value() on “v”
> (from cleanup_on_restart), which clears v->in_global_register and
> v->in_register, leaving “v” in a slightly different state the second time
> codegen starts. So, when the second compilation hits the add instruction at
> the very top (the first instruction that uses v in the block/instruction
> iteration order), it assumes it needs to load it from the stack.
>
>
> I’m not sure what the correct fix is here, but it seems like the value state
> should be consistent across compile restarts.