Returning b64 results in a segmentation fault

[abrown]

As a part of #890 I added support for running CLIF directly as a filetest or through clif-util run; the current idea is that functions would return a boolean that indicates whether the function ran successfully or not. This works with the other boolean types, but a test like the following results in a segmentation fault:

test run
function %test_b64() -> b64 {
ebb0:
    v0 = bconst.b64 true
    return v0
}
; run

$ target/debug/clif-util run filetests/isa/x86/run-const.clif 
Segmentation fault (core dumped)
$ coredumpctl dump
           PID: 32159 (clif-util)
           UID: 1000 (abrown)
           GID: 1000 (abrown)
        Signal: 11 (SEGV)
     Timestamp: Tue 2019-08-20 09:15:19 PDT (1min 36s ago)
  Command Line: target/debug/clif-util run filetests/isa/x86/run-const.clif
    Executable: /home/abrown/Code/cranelift/target/debug/clif-util
 Control Group: /user.slice/user-1000.slice/session-c3.scope
          Unit: session-c3.scope
         Slice: user-1000.slice
       Session: c3
     Owner UID: 1000 (abrown)
       Boot ID: 118deca6420a48b69f1c2a455c2500f9
    Machine ID: e9d29f116e2f4d09baf478e99d04fbff
      Hostname: abrown-desk.amr.corp.intel.com
       Storage: /var/lib/systemd/coredump/core.clif-util.1000.118deca6420a48b69f1c2a455c2500f9.32159.1566317719000000.lz4
       Message: Process 32159 (clif-util) of user 1000 dumped core.
                
                Stack trace of thread 32159:
                #0  0x00007fec72edc00f n/a (ld-linux-x86-64.so.2)
                #1  0x00005642de402114 n/a (/home/abrown/Code/cranelift/target/debug/clif-util)

I am running a Linux kernel 5.1.18 on Fedora 30 and would expect the system_v calling convention to be the default here. I may need some help figuring out why b64 does not work here.

[bjorn3]

Can you get a disassembly of the crashing function + which instruction is the culprit. Eg:

$ lldb -- target/debug/clif-util run filetests/isa/x86/run-const.clif
(lldb) run
(lldb) disassemble

[abrown]

Ok, the above didn't work too well but here is my version:

(lldb) break set --file cranelift-filetests/src/function_runner.rs --line 86
Breakpoint 1: where = clif-util`cranelift_filetests::function_runner::FunctionRunner::run::h72bb96537b5bd75f + 2438 at function_runner.rs:86:14, address = 0x0000555555a66f66

(lldb) run
[...]

(lldb) si
Process 20194 stopped
* thread #1, name = 'clif-util', stop reason = instruction step into
    frame #0: 0x0000555555a66f6e clif-util`cranelift_filetests::function_runner::FunctionRunner::run::h72bb96537b5bd75f(self=0x00007fffffff0a00) at function_runner.rs:86:14
   83           };
   84   
   85           // execute
-> 86           match callable_fn() {
   87               true => Ok(()),
   88               false => Err(format!("Failed: {}", context.func.name.to_string())),
   89           }

(lldb) disassemble
->  0x7ffff7ffb000: pushq  %rbp
    0x7ffff7ffb002: movq   %rsp, %rbp
    0x7ffff7ffb005: movabsq $0xc35d4000000001, %rax   ; imm = 0xC35D4000000001 
    0x7ffff7ffb00f: addb   %al, (%rax)
    0x7ffff7ffb011: addb   %al, (%rax)
    0x7ffff7ffb013: addb   %al, (%rax)
    ...

It may be that movabsq is the right instruction but two things are weird:

• 0xC35D4?
• no ret instruction nearby?

[bjorn3]

Could you please run step. You didnt step into the function generated by clif yet. :)

[abrown]

Sorry, didn't copy all of the output; I ran si a couple of times (but elided them) until I got into the assembled code. I used si because I need the instruction-level granularity here. So the disassemble is inside the emitted code.

[bnjbvr]

Well, I can see the ret: C3 is one of x86's forms of ret, so there's probably something wrong with a relocation or binemit here...

[bnjbvr]

The x86 encoding is incorrect for bconst.bind(B64): it uses a recipe that emits a 32-bit immediate, while it should use one that emits a 64-bit immediate. This calls for a pu_iq_bool recipe for use for this recipe.