[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libjit] Miscompilation problem
From: |
Aleksey Demakov |
Subject: |
Re: [Libjit] Miscompilation problem |
Date: |
Wed, 10 Jan 2018 09:17:42 +0300 |
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.