[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libjit] Miscompilation problem

From: David Meyer
Subject: [Libjit] Miscompilation problem
Date: Mon, 8 Jan 2018 13:39:53 +0000

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.

Attachment: minimal.c
Description: minimal.c

reply via email to

[Prev in Thread] Current Thread [Next in Thread]