afonso360 opened issue #5569:
:wave: Hey,
Fuzzgen found this a week or so ago, but I haven't been able to minimize this. Whenever I try to remove seemingly any instruction the test case passes.
I'm going to keep running fuzzgen with a smaller
max_len
to try to find a smaller example.
.clif
Test CaseSteps to Reproduce
clif-util test ./the-above.clif
Expected Results
The test to pass
Actual Results
afonso@DESKTOP-VSTS4BC:~/git/wasmtime/cranelift$ cargo run --target riscv64gc-unknown-linux-gnu -- test ./lmao.clif Finished dev [unoptimized + debuginfo] target(s) in 0.16s Running `qemu-riscv64 -L /usr/riscv64-linux-gnu -E LD_LIBRARY_PATH=/usr/riscv64-linux-gnu/lib /home/afonso/git/wasmtime/target/riscv64gc-unknown-linux-gnu/debug/clif-util test ./lmao.clif` Illegal instruction
Versions and Environment
Cranelift version or commit: main
Operating system: linux
Architecture: riscv64Extra Info
Disassembly
Running this under GDB it crashes in:
0x3ff7fd5b70: bne zero,a7,0x3ff7fd5b78 0x3ff7fd5b74: unimp 0x3ff7fd5b76: unimp 0x3ff7fd5b78: divw t2,a6,a7 0x3ff7fd5b7c: feq.d a2,fa0,fa0 0x3ff7fd5b80: beqz a2,0x3ff7fd5b90 0x3ff7fd5b84: auipc t6,0x0 0x3ff7fd5b88: ld t6,12(t6) 0x3ff7fd5b8c: j 0x3ff7fd5b98 0x3ff7fd5b90: auipc t6,0x0 0x3ff7fd5b94: jr 48(t6) => 0x3ff7fd5b98: unimp 0x3ff7fd5b9a: unimp 0x3ff7fd5b9c: unimp 0x3ff7fd5b9e: lw s0,4(a4) 0x3ff7fd5ba0: fmv.d.x fa3,t6 0x3ff7fd5ba4: fabs.d fa1,fa0 0x3ff7fd5ba8: flt.d a2,fa3,fa1 0x3ff7fd5bac: bnez a2,0x3ff7fd5bc8 0x3ff7fd5bb0: fcvt.l.d a2,fa0,rne
The start of the function is at
0x3ff7fd4000
, so this is at offset0x1B98
in the disassembly. Which appears to be a embedded constant?1b88: 83 bf cf 00 ld t6, 0xc(t6) 1b8c: 6f 00 c0 00 j 0xc 1b90: 97 0f 00 00 auipc t6, 0 1b94: 67 80 0f 03 jalr zero, t6, 0x30 1b98: 00 00 00 00 .byte 0x00, 0x00, 0x00, 0x00 1b9c: 00 00 40 43 .byte 0x00, 0x00, 0x40, 0x43 1ba0: d3 86 0f f2 fmv.d.x fa3, t6
I suspect the issue here is that the instruction at
1b8c
is a jump directly into the embedded constant at1b98
.Looking at the trace logs for this range, it looks like we are emitting a veneer right at that offset? And maybe we have a constant offset in some branch that is causing this.
1b8c = 7052
1b98 = 7064
TRACE cranelift_codegen::machinst::buffer > emit_island: fixup MachLabelFixup { label: MachLabel(529), offset: 7040, kind: B12 } TRACE cranelift_codegen::machinst::buffer > MachBuffer: align to 4 TRACE cranelift_codegen::machinst::buffer > making a veneer at 7056 TRACE cranelift_codegen::machinst::buffer > patching original at offset 7040 to veneer offset 7056 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put data @ 7056: len 8 TRACE cranelift_codegen::machinst::buffer > generated veneer; fixup offset 7056, label_use PCRel32 TRACE cranelift_codegen::machinst::buffer > MachBuffer: use_label_at_offset: offset 7056 label MachLabel(529) kind PCRel32 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put data @ 7064: len 8 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7072: f20f86d3 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7076: 22a525d3 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7080: a2b69653 TRACE cranelift_codegen::machinst::buffer > MachBuffer: use_label_at_offset: offset 7084 label MachLabel(530) kind B12
I'm not too sure how to translate these offsets into an actual clif instruction that is causing this issue.
afonso360 labeled issue #5569:
:wave: Hey,
Fuzzgen found this a week or so ago, but I haven't been able to minimize this. Whenever I try to remove seemingly any instruction the test case passes.
I'm going to keep running fuzzgen with a smaller
max_len
to try to find a smaller example.
.clif
Test CaseSteps to Reproduce
clif-util test ./the-above.clif
Expected Results
The test to pass
Actual Results
afonso@DESKTOP-VSTS4BC:~/git/wasmtime/cranelift$ cargo run --target riscv64gc-unknown-linux-gnu -- test ./lmao.clif Finished dev [unoptimized + debuginfo] target(s) in 0.16s Running `qemu-riscv64 -L /usr/riscv64-linux-gnu -E LD_LIBRARY_PATH=/usr/riscv64-linux-gnu/lib /home/afonso/git/wasmtime/target/riscv64gc-unknown-linux-gnu/debug/clif-util test ./lmao.clif` Illegal instruction
Versions and Environment
Cranelift version or commit: main
Operating system: linux
Architecture: riscv64Extra Info
Disassembly
Running this under GDB it crashes in:
0x3ff7fd5b70: bne zero,a7,0x3ff7fd5b78 0x3ff7fd5b74: unimp 0x3ff7fd5b76: unimp 0x3ff7fd5b78: divw t2,a6,a7 0x3ff7fd5b7c: feq.d a2,fa0,fa0 0x3ff7fd5b80: beqz a2,0x3ff7fd5b90 0x3ff7fd5b84: auipc t6,0x0 0x3ff7fd5b88: ld t6,12(t6) 0x3ff7fd5b8c: j 0x3ff7fd5b98 0x3ff7fd5b90: auipc t6,0x0 0x3ff7fd5b94: jr 48(t6) => 0x3ff7fd5b98: unimp 0x3ff7fd5b9a: unimp 0x3ff7fd5b9c: unimp 0x3ff7fd5b9e: lw s0,4(a4) 0x3ff7fd5ba0: fmv.d.x fa3,t6 0x3ff7fd5ba4: fabs.d fa1,fa0 0x3ff7fd5ba8: flt.d a2,fa3,fa1 0x3ff7fd5bac: bnez a2,0x3ff7fd5bc8 0x3ff7fd5bb0: fcvt.l.d a2,fa0,rne
The start of the function is at
0x3ff7fd4000
, so this is at offset0x1B98
in the disassembly. Which appears to be a embedded constant?1b88: 83 bf cf 00 ld t6, 0xc(t6) 1b8c: 6f 00 c0 00 j 0xc 1b90: 97 0f 00 00 auipc t6, 0 1b94: 67 80 0f 03 jalr zero, t6, 0x30 1b98: 00 00 00 00 .byte 0x00, 0x00, 0x00, 0x00 1b9c: 00 00 40 43 .byte 0x00, 0x00, 0x40, 0x43 1ba0: d3 86 0f f2 fmv.d.x fa3, t6
I suspect the issue here is that the instruction at
1b8c
is a jump directly into the embedded constant at1b98
.Looking at the trace logs for this range, it looks like we are emitting a veneer right at that offset? And maybe we have a constant offset in some branch that is causing this.
1b8c = 7052
1b98 = 7064
TRACE cranelift_codegen::machinst::buffer > emit_island: fixup MachLabelFixup { label: MachLabel(529), offset: 7040, kind: B12 } TRACE cranelift_codegen::machinst::buffer > MachBuffer: align to 4 TRACE cranelift_codegen::machinst::buffer > making a veneer at 7056 TRACE cranelift_codegen::machinst::buffer > patching original at offset 7040 to veneer offset 7056 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put data @ 7056: len 8 TRACE cranelift_codegen::machinst::buffer > generated veneer; fixup offset 7056, label_use PCRel32 TRACE cranelift_codegen::machinst::buffer > MachBuffer: use_label_at_offset: offset 7056 label MachLabel(529) kind PCRel32 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put data @ 7064: len 8 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7072: f20f86d3 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7076: 22a525d3 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7080: a2b69653 TRACE cranelift_codegen::machinst::buffer > MachBuffer: use_label_at_offset: offset 7084 label MachLabel(530) kind B12
I'm not too sure how to translate these offsets into an actual clif instruction that is causing this issue.
afonso360 labeled issue #5569:
:wave: Hey,
Fuzzgen found this a week or so ago, but I haven't been able to minimize this. Whenever I try to remove seemingly any instruction the test case passes.
I'm going to keep running fuzzgen with a smaller
max_len
to try to find a smaller example.
.clif
Test CaseSteps to Reproduce
clif-util test ./the-above.clif
Expected Results
The test to pass
Actual Results
afonso@DESKTOP-VSTS4BC:~/git/wasmtime/cranelift$ cargo run --target riscv64gc-unknown-linux-gnu -- test ./lmao.clif Finished dev [unoptimized + debuginfo] target(s) in 0.16s Running `qemu-riscv64 -L /usr/riscv64-linux-gnu -E LD_LIBRARY_PATH=/usr/riscv64-linux-gnu/lib /home/afonso/git/wasmtime/target/riscv64gc-unknown-linux-gnu/debug/clif-util test ./lmao.clif` Illegal instruction
Versions and Environment
Cranelift version or commit: main
Operating system: linux
Architecture: riscv64Extra Info
Disassembly
Running this under GDB it crashes in:
0x3ff7fd5b70: bne zero,a7,0x3ff7fd5b78 0x3ff7fd5b74: unimp 0x3ff7fd5b76: unimp 0x3ff7fd5b78: divw t2,a6,a7 0x3ff7fd5b7c: feq.d a2,fa0,fa0 0x3ff7fd5b80: beqz a2,0x3ff7fd5b90 0x3ff7fd5b84: auipc t6,0x0 0x3ff7fd5b88: ld t6,12(t6) 0x3ff7fd5b8c: j 0x3ff7fd5b98 0x3ff7fd5b90: auipc t6,0x0 0x3ff7fd5b94: jr 48(t6) => 0x3ff7fd5b98: unimp 0x3ff7fd5b9a: unimp 0x3ff7fd5b9c: unimp 0x3ff7fd5b9e: lw s0,4(a4) 0x3ff7fd5ba0: fmv.d.x fa3,t6 0x3ff7fd5ba4: fabs.d fa1,fa0 0x3ff7fd5ba8: flt.d a2,fa3,fa1 0x3ff7fd5bac: bnez a2,0x3ff7fd5bc8 0x3ff7fd5bb0: fcvt.l.d a2,fa0,rne
The start of the function is at
0x3ff7fd4000
, so this is at offset0x1B98
in the disassembly. Which appears to be a embedded constant?1b88: 83 bf cf 00 ld t6, 0xc(t6) 1b8c: 6f 00 c0 00 j 0xc 1b90: 97 0f 00 00 auipc t6, 0 1b94: 67 80 0f 03 jalr zero, t6, 0x30 1b98: 00 00 00 00 .byte 0x00, 0x00, 0x00, 0x00 1b9c: 00 00 40 43 .byte 0x00, 0x00, 0x40, 0x43 1ba0: d3 86 0f f2 fmv.d.x fa3, t6
I suspect the issue here is that the instruction at
1b8c
is a jump directly into the embedded constant at1b98
.Looking at the trace logs for this range, it looks like we are emitting a veneer right at that offset? And maybe we have a constant offset in some branch that is causing this.
1b8c = 7052
1b98 = 7064
TRACE cranelift_codegen::machinst::buffer > emit_island: fixup MachLabelFixup { label: MachLabel(529), offset: 7040, kind: B12 } TRACE cranelift_codegen::machinst::buffer > MachBuffer: align to 4 TRACE cranelift_codegen::machinst::buffer > making a veneer at 7056 TRACE cranelift_codegen::machinst::buffer > patching original at offset 7040 to veneer offset 7056 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put data @ 7056: len 8 TRACE cranelift_codegen::machinst::buffer > generated veneer; fixup offset 7056, label_use PCRel32 TRACE cranelift_codegen::machinst::buffer > MachBuffer: use_label_at_offset: offset 7056 label MachLabel(529) kind PCRel32 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put data @ 7064: len 8 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7072: f20f86d3 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7076: 22a525d3 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7080: a2b69653 TRACE cranelift_codegen::machinst::buffer > MachBuffer: use_label_at_offset: offset 7084 label MachLabel(530) kind B12
I'm not too sure how to translate these offsets into an actual clif instruction that is causing this issue.
afonso360 edited issue #5569:
:wave: Hey,
Fuzzgen found this a week or so ago, but I haven't been able to minimize this. Whenever I try to remove seemingly any instruction the test case passes.
I'm going to keep running fuzzgen with a smaller
max_len
to try to find a smaller example.
.clif
Test CaseSteps to Reproduce
clif-util test ./the-above.clif
Expected Results
The test to pass
Actual Results
afonso@DESKTOP-VSTS4BC:~/git/wasmtime/cranelift$ cargo run --target riscv64gc-unknown-linux-gnu -- test ./lmao.clif Finished dev [unoptimized + debuginfo] target(s) in 0.16s Running `qemu-riscv64 -L /usr/riscv64-linux-gnu -E LD_LIBRARY_PATH=/usr/riscv64-linux-gnu/lib /home/afonso/git/wasmtime/target/riscv64gc-unknown-linux-gnu/debug/clif-util test ./lmao.clif` Illegal instruction
Versions and Environment
Cranelift version or commit: main
Operating system: linux
Architecture: riscv64Extra Info
Disassembly
Running this under GDB it crashes in:
0x3ff7fd5b70: bne zero,a7,0x3ff7fd5b78 0x3ff7fd5b74: unimp 0x3ff7fd5b76: unimp 0x3ff7fd5b78: divw t2,a6,a7 0x3ff7fd5b7c: feq.d a2,fa0,fa0 0x3ff7fd5b80: beqz a2,0x3ff7fd5b90 0x3ff7fd5b84: auipc t6,0x0 0x3ff7fd5b88: ld t6,12(t6) 0x3ff7fd5b8c: j 0x3ff7fd5b98 0x3ff7fd5b90: auipc t6,0x0 0x3ff7fd5b94: jr 48(t6) => 0x3ff7fd5b98: unimp 0x3ff7fd5b9a: unimp 0x3ff7fd5b9c: unimp 0x3ff7fd5b9e: lw s0,4(a4) 0x3ff7fd5ba0: fmv.d.x fa3,t6 0x3ff7fd5ba4: fabs.d fa1,fa0 0x3ff7fd5ba8: flt.d a2,fa3,fa1 0x3ff7fd5bac: bnez a2,0x3ff7fd5bc8 0x3ff7fd5bb0: fcvt.l.d a2,fa0,rne
The start of the function is at
0x3ff7fd4000
, so this is at offset0x1B98
in the disassembly. Which appears to be a embedded constant?1b88: 83 bf cf 00 ld t6, 0xc(t6) 1b8c: 6f 00 c0 00 j 0xc 1b90: 97 0f 00 00 auipc t6, 0 1b94: 67 80 0f 03 jalr zero, t6, 0x30 1b98: 00 00 00 00 .byte 0x00, 0x00, 0x00, 0x00 1b9c: 00 00 40 43 .byte 0x00, 0x00, 0x40, 0x43 1ba0: d3 86 0f f2 fmv.d.x fa3, t6
I suspect the issue here is that the instruction at
1b8c
is a jump directly into the embedded constant at1b98
.Looking at the trace logs for this range, it looks like we are emitting a veneer right at that offset? And maybe we have a constant offset in some branch that is causing this.
1b8c = 7052
1b98 = 7064
TRACE cranelift_codegen::machinst::buffer > emit_island: fixup MachLabelFixup { label: MachLabel(529), offset: 7040, kind: B12 } TRACE cranelift_codegen::machinst::buffer > MachBuffer: align to 4 TRACE cranelift_codegen::machinst::buffer > making a veneer at 7056 TRACE cranelift_codegen::machinst::buffer > patching original at offset 7040 to veneer offset 7056 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put data @ 7056: len 8 TRACE cranelift_codegen::machinst::buffer > generated veneer; fixup offset 7056, label_use PCRel32 TRACE cranelift_codegen::machinst::buffer > MachBuffer: use_label_at_offset: offset 7056 label MachLabel(529) kind PCRel32 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put data @ 7064: len 8 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7072: f20f86d3 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7076: 22a525d3 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7080: a2b69653 TRACE cranelift_codegen::machinst::buffer > MachBuffer: use_label_at_offset: offset 7084 label MachLabel(530) kind B12
I'm not too sure how to translate these offsets into an actual clif instruction that is causing this issue.
Edit: This seems to be caused by us not using labels in
load_constant
.
alexcrichton labeled issue #5569:
:wave: Hey,
Fuzzgen found this a week or so ago, but I haven't been able to minimize this. Whenever I try to remove seemingly any instruction the test case passes.
I'm going to keep running fuzzgen with a smaller
max_len
to try to find a smaller example.
.clif
Test CaseSteps to Reproduce
clif-util test ./the-above.clif
Expected Results
The test to pass
Actual Results
afonso@DESKTOP-VSTS4BC:~/git/wasmtime/cranelift$ cargo run --target riscv64gc-unknown-linux-gnu -- test ./lmao.clif Finished dev [unoptimized + debuginfo] target(s) in 0.16s Running `qemu-riscv64 -L /usr/riscv64-linux-gnu -E LD_LIBRARY_PATH=/usr/riscv64-linux-gnu/lib /home/afonso/git/wasmtime/target/riscv64gc-unknown-linux-gnu/debug/clif-util test ./lmao.clif` Illegal instruction
Versions and Environment
Cranelift version or commit: main
Operating system: linux
Architecture: riscv64Extra Info
Disassembly
Running this under GDB it crashes in:
0x3ff7fd5b70: bne zero,a7,0x3ff7fd5b78 0x3ff7fd5b74: unimp 0x3ff7fd5b76: unimp 0x3ff7fd5b78: divw t2,a6,a7 0x3ff7fd5b7c: feq.d a2,fa0,fa0 0x3ff7fd5b80: beqz a2,0x3ff7fd5b90 0x3ff7fd5b84: auipc t6,0x0 0x3ff7fd5b88: ld t6,12(t6) 0x3ff7fd5b8c: j 0x3ff7fd5b98 0x3ff7fd5b90: auipc t6,0x0 0x3ff7fd5b94: jr 48(t6) => 0x3ff7fd5b98: unimp 0x3ff7fd5b9a: unimp 0x3ff7fd5b9c: unimp 0x3ff7fd5b9e: lw s0,4(a4) 0x3ff7fd5ba0: fmv.d.x fa3,t6 0x3ff7fd5ba4: fabs.d fa1,fa0 0x3ff7fd5ba8: flt.d a2,fa3,fa1 0x3ff7fd5bac: bnez a2,0x3ff7fd5bc8 0x3ff7fd5bb0: fcvt.l.d a2,fa0,rne
The start of the function is at
0x3ff7fd4000
, so this is at offset0x1B98
in the disassembly. Which appears to be a embedded constant?1b88: 83 bf cf 00 ld t6, 0xc(t6) 1b8c: 6f 00 c0 00 j 0xc 1b90: 97 0f 00 00 auipc t6, 0 1b94: 67 80 0f 03 jalr zero, t6, 0x30 1b98: 00 00 00 00 .byte 0x00, 0x00, 0x00, 0x00 1b9c: 00 00 40 43 .byte 0x00, 0x00, 0x40, 0x43 1ba0: d3 86 0f f2 fmv.d.x fa3, t6
I suspect the issue here is that the instruction at
1b8c
is a jump directly into the embedded constant at1b98
.Looking at the trace logs for this range, it looks like we are emitting a veneer right at that offset? And maybe we have a constant offset in some branch that is causing this.
1b8c = 7052
1b98 = 7064
TRACE cranelift_codegen::machinst::buffer > emit_island: fixup MachLabelFixup { label: MachLabel(529), offset: 7040, kind: B12 } TRACE cranelift_codegen::machinst::buffer > MachBuffer: align to 4 TRACE cranelift_codegen::machinst::buffer > making a veneer at 7056 TRACE cranelift_codegen::machinst::buffer > patching original at offset 7040 to veneer offset 7056 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put data @ 7056: len 8 TRACE cranelift_codegen::machinst::buffer > generated veneer; fixup offset 7056, label_use PCRel32 TRACE cranelift_codegen::machinst::buffer > MachBuffer: use_label_at_offset: offset 7056 label MachLabel(529) kind PCRel32 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put data @ 7064: len 8 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7072: f20f86d3 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7076: 22a525d3 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7080: a2b69653 TRACE cranelift_codegen::machinst::buffer > MachBuffer: use_label_at_offset: offset 7084 label MachLabel(530) kind B12
I'm not too sure how to translate these offsets into an actual clif instruction that is causing this issue.
Edit: This seems to be caused by us not using labels in
load_constant
.
yuyang-ok commented on issue #5569:
@alexcrichton @afonso360 I think I fixed this. :-)
afonso360 closed issue #5569:
:wave: Hey,
Fuzzgen found this a week or so ago, but I haven't been able to minimize this. Whenever I try to remove seemingly any instruction the test case passes.
I'm going to keep running fuzzgen with a smaller
max_len
to try to find a smaller example.
.clif
Test CaseSteps to Reproduce
clif-util test ./the-above.clif
Expected Results
The test to pass
Actual Results
afonso@DESKTOP-VSTS4BC:~/git/wasmtime/cranelift$ cargo run --target riscv64gc-unknown-linux-gnu -- test ./lmao.clif Finished dev [unoptimized + debuginfo] target(s) in 0.16s Running `qemu-riscv64 -L /usr/riscv64-linux-gnu -E LD_LIBRARY_PATH=/usr/riscv64-linux-gnu/lib /home/afonso/git/wasmtime/target/riscv64gc-unknown-linux-gnu/debug/clif-util test ./lmao.clif` Illegal instruction
Versions and Environment
Cranelift version or commit: main
Operating system: linux
Architecture: riscv64Extra Info
Disassembly
Running this under GDB it crashes in:
0x3ff7fd5b70: bne zero,a7,0x3ff7fd5b78 0x3ff7fd5b74: unimp 0x3ff7fd5b76: unimp 0x3ff7fd5b78: divw t2,a6,a7 0x3ff7fd5b7c: feq.d a2,fa0,fa0 0x3ff7fd5b80: beqz a2,0x3ff7fd5b90 0x3ff7fd5b84: auipc t6,0x0 0x3ff7fd5b88: ld t6,12(t6) 0x3ff7fd5b8c: j 0x3ff7fd5b98 0x3ff7fd5b90: auipc t6,0x0 0x3ff7fd5b94: jr 48(t6) => 0x3ff7fd5b98: unimp 0x3ff7fd5b9a: unimp 0x3ff7fd5b9c: unimp 0x3ff7fd5b9e: lw s0,4(a4) 0x3ff7fd5ba0: fmv.d.x fa3,t6 0x3ff7fd5ba4: fabs.d fa1,fa0 0x3ff7fd5ba8: flt.d a2,fa3,fa1 0x3ff7fd5bac: bnez a2,0x3ff7fd5bc8 0x3ff7fd5bb0: fcvt.l.d a2,fa0,rne
The start of the function is at
0x3ff7fd4000
, so this is at offset0x1B98
in the disassembly. Which appears to be a embedded constant?1b88: 83 bf cf 00 ld t6, 0xc(t6) 1b8c: 6f 00 c0 00 j 0xc 1b90: 97 0f 00 00 auipc t6, 0 1b94: 67 80 0f 03 jalr zero, t6, 0x30 1b98: 00 00 00 00 .byte 0x00, 0x00, 0x00, 0x00 1b9c: 00 00 40 43 .byte 0x00, 0x00, 0x40, 0x43 1ba0: d3 86 0f f2 fmv.d.x fa3, t6
I suspect the issue here is that the instruction at
1b8c
is a jump directly into the embedded constant at1b98
.Looking at the trace logs for this range, it looks like we are emitting a veneer right at that offset? And maybe we have a constant offset in some branch that is causing this.
1b8c = 7052
1b98 = 7064
TRACE cranelift_codegen::machinst::buffer > emit_island: fixup MachLabelFixup { label: MachLabel(529), offset: 7040, kind: B12 } TRACE cranelift_codegen::machinst::buffer > MachBuffer: align to 4 TRACE cranelift_codegen::machinst::buffer > making a veneer at 7056 TRACE cranelift_codegen::machinst::buffer > patching original at offset 7040 to veneer offset 7056 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put data @ 7056: len 8 TRACE cranelift_codegen::machinst::buffer > generated veneer; fixup offset 7056, label_use PCRel32 TRACE cranelift_codegen::machinst::buffer > MachBuffer: use_label_at_offset: offset 7056 label MachLabel(529) kind PCRel32 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put data @ 7064: len 8 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7072: f20f86d3 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7076: 22a525d3 TRACE cranelift_codegen::machinst::buffer > MachBuffer: put 32-bit word @ 7080: a2b69653 TRACE cranelift_codegen::machinst::buffer > MachBuffer: use_label_at_offset: offset 7084 label MachLabel(530) kind B12
I'm not too sure how to translate these offsets into an actual clif instruction that is causing this issue.
Edit: This seems to be caused by us not using labels in
load_constant
.
Last updated: Nov 22 2024 at 16:03 UTC