bjorn3 opened Issue #1305:
What are the steps to reproduce the issue? Can you include a CLIF test case,
ideally reduced with thebugpoint
clif-util command? https://travis-ci.org/bjorn3/rustc_codegen_cranelift/jobs/627882870What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion? SIGSEGV in coretests test.Which Cranelift version / commit hash / branch are you using? e0d317249194f51a80c97a856f96eea1560c5435
Regression range: https://github.com/bytecodealliance/cranelift/compare/ec787eb281bb2e18e191508c17abe694e91f0677...e0d317249194f51a80c97a856f96eea1560c5435
Likely caused by #1298 (cc @sstangl)
bjorn3 labeled Issue #1305:
What are the steps to reproduce the issue? Can you include a CLIF test case,
ideally reduced with thebugpoint
clif-util command? https://travis-ci.org/bjorn3/rustc_codegen_cranelift/jobs/627882870What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion? SIGSEGV in coretests test.Which Cranelift version / commit hash / branch are you using? e0d317249194f51a80c97a856f96eea1560c5435
Regression range: https://github.com/bytecodealliance/cranelift/compare/ec787eb281bb2e18e191508c17abe694e91f0677...e0d317249194f51a80c97a856f96eea1560c5435
Likely caused by #1298 (cc @sstangl)
sstangl commented on Issue #1305:
Is there a way this can be reproduced? Even without a CLIF file, the change could be reversed piecewise by changing the
i32_i64
function toi32_i64_explicit_rex
, at least narrowing down which recipe is likely responsible.
bjorn3 commented on Issue #1305:
Just follow the build instructions of https://github.com/bjorn3/rustc_codegen_cranelift. If you remove https://github.com/bjorn3/rustc_codegen_cranelift/blob/master/test.sh#L69-L78, it will be quite a bit faster to test.
Even without a CLIF file, the change could be reversed piecewise by changing the i32_i64 function to i32_i64_explicit_rex, at least narrowing down which recipe is likely responsible.
Will try tomorrow.
sstangl commented on Issue #1305:
Hum, I get this:
[codegen mono items] end time: 483.21918ms
error: could not compilecore
.Caused by:
process didn't exit successfully:rustc --edition=2018 --crate-name core sysroot_src/src/libcore/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 -C metadata=53bf39f7e0485e6c -C extra-filename=-53bf39f7e0485e6c --out-dir /home/sstangl/dev/rustc_codegen_cranelift/build_sysroot/target/x86_64-unknown-linux-gnu/debug/deps --target x86_64-unknown-linux-gnu -C incremental=/home/sstangl/dev/rustc_codegen_cranelift/build_sysroot/target/x86_64-unknown-linux-gnu/debug/incremental -L dependency=/home/sstangl/dev/rustc_codegen_cranelift/build_sysroot/target/x86_64-unknown-linux-gnu/debug/deps -L dependency=/home/sstangl/dev/rustc_codegen_cranelift/build_sysroot/target/debug/deps -Cpanic=abort -Cdebuginfo=2 -Zpanic-abort-tests -Zcodegen-backend=/home/sstangl/dev/rustc_codegen_cranelift/target/debug/librustc_codegen_cranelift.so --sysroot /home/sstangl/dev/rustc_codegen_cranelift/build_sysroot/sysroot -Z force-unstable-if-unmarked
(signal: 4, SIGILL: illegal instruction)Which, if I'm reading that right, is rustc crashing?
sstangl commented on Issue #1305:
Do I need to be on a specific version of rustc to compile this? The build instructions didn't mention it.
bjorn3 commented on Issue #1305:
The travis build is using latest nightly.
Which, if I'm reading that right, is rustc crashing?
Seems so, the travis build fails with:
error: test failed, to rerun pass '--lib'
Caused by:
process didn't exit successfully:
/Users/travis/build/bjorn3/rustc_codegen_cranelift/build_sysroot/sysroot_src/src/libcore/tests/target/x86_64-apple-darwin/debug/deps/coretests-a2d3b493e4d8f1a3
(signal: 11, SIGSEGV: invalid memory reference)What is the output above the error for you?
bjorn3 commented on Issue #1305:
The pc ends up in the middle of an instruction. A breakpoint at the start of the function doesn't get triggered.
sstangl closed Issue #1305:
What are the steps to reproduce the issue? Can you include a CLIF test case,
ideally reduced with thebugpoint
clif-util command? https://travis-ci.org/bjorn3/rustc_codegen_cranelift/jobs/627882870What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion? SIGSEGV in coretests test.Which Cranelift version / commit hash / branch are you using? e0d317249194f51a80c97a856f96eea1560c5435
Regression range: https://github.com/bytecodealliance/cranelift/compare/ec787eb281bb2e18e191508c17abe694e91f0677...e0d317249194f51a80c97a856f96eea1560c5435
Likely caused by #1298 (cc @sstangl)
bjorn3 commented on Issue #1305:
I can confirm that this issue is fixed: https://travis-ci.org/bjorn3/rustc_codegen_cranelift/jobs/628398038
bnjbvr commented on Issue #1305:
Just follow the build instructions
Sorry @bjorn3, but this won't scale if we have to do this for every project embedding Cranelift. Please provide a CLIF test case next time, so we can include it in Cranelift's regression test suite.
bjorn3 commented on Issue #1305:
I understand that it would be much nicer to just provide some clif ir with the bug. However this was a runtime error, but I didn't know where the problem was, so I would have to provide the clif ir of every compiled function. Because I use cranelift_module, that would still miss information necessary to actually compile and run it.
bnjbvr commented on Issue #1305:
I understand the difficulty, but for us it's even more work to try to understand your code base, figure out how it uses Cranelift, etc.
Since you have a test case with a segfault at a precise instruction pointer value, could you please:
- add debug print to show the effective code ranges for each compiled function
- run in a debugger (gdb, or rr is even better in this kind of situations) and note down the value of the instruction pointer when the crash happens
- find which function is affected by this issue
- get the CLIF for this particular function?
And then we can figure it out from there. Having a test case is a great deal in effectively fixing a regression.
I think that having item (1) in cranelift-module in general would make sense to make debugging easier (behind an environment option / compile option / controlled by a parameter or whatnot).
bjorn3 commented on Issue #1305:
I completely agree that it would be nicer to have a test case rather than a big program to compile and run. I try to create a test case when possible. In this particular case that was however not really possible, as there was a jump somewhere to the middle of an instruction, after which the process continued running. I did try to reduce the test case, but even slight changes made it stop crash, crash at a different place or even jump to an unmapped page. This made it hard to find the responsible instruction or even function. rr would have made it easy, but it doesn't work on macOS, which I was using that day.
find which function is affected by this issue
The debugger showed me which function was running when it finally crashed (both faerie and object emit symbols for every function, even if private), but at that point the ip was already pointing in the middle of an instruction.
bnjbvr commented on Issue #1305:
The debugger showed me which function was running when it finally crashed (both faerie and object emit symbols for every function, even if private), but at that point the ip was already pointing in the middle of an instruction.
I see. Note that the aforementioned rr is a record and replay debugger, so it allows you to run your code backwards: from the point where it crashed, you can do
rsi
(reverse step instruction) to see what the previous instruction was. It's a bit of work to install it first, but the payoff is great in situations like this, and I am confident it would help in your Rustc endeavors as well.
Last updated: Dec 23 2024 at 13:07 UTC