Some examples in mos-hardware are miscompiled or mislinked

[p2mate]

When compiling https://github.com/mlund/mos-hardware/blob/main/examples/c64-raster-interrupt.rs the resulting binary does not call main. See attached file. I don't think this is a bug in rustc, but possibly in LLVM or llvm-mos-sdk?

If I binary patch the jump at 0x837 to jump to 0x971 instead of 0x857, the program works.

output.txt

[mlund]

I just tried to compile using the latest Docker image, mrkits/rust-mos:latest, and it works for me. I did this by compiling directly from the mos-hardware directory with

cargo build --release --example c64-raster-interrupt --target mos-c64-none

[p2mate]

yes, that's what I do as well. Using the following commits for my build:

mos-hardware 041e678404dd8a32ec81f8e7c70560d42a383bf9 rust-mos 1c70e860612a0f6c6a88584f17094e966ab1d06f llvm-mos-sdk 0777f80b84195eea83d626d33ab786b089c75c6d llvm-mos 9a8981cfd5c72c2e60151ce670cd56acc5b57148

[mlund]

I still haven't managed to build rust-mos and use only the docker image above which would have slightly older revisions. Did you try with that? I understand from other issues here, that later llvm-mos could be problematic.

[sagacity]

Building the idiomatic plasma example in release mode also causes a miscompilation, even with the rust-mos docker image and the latest commit (fdf984ddfc69c971c2da020f52542566761fc268) in mos-hardware. The application starts but once the precalc is done the screen messes up.

Building in debug mode works fine, though!

[mlund]

I cannot reproduce the issue for the idiomatic plasma example; do you compile directly from the crate? I have only had issues with compilation in projects that use mos-hardware as a dependency (I suspect it has to do with LTO).

[sagacity]

@mlund, this was compiled from a separate crate (based on mos-hardware-template).

I tried turning off LTO (so opt-level ="s", lto = false, debug = 2), but that resulted in:

LLVM ERROR: unable to legalize instruction: %13:_(s1) = G_FCMP floatpred(ord), %0:_(s32), %12:_ (in function: _ZN4core3f3221_$LT$impl$u20$f32$GT$8classify17hdbccd96cbb9378daE)
error: could not compile `core`

Turning on LTO again caused compilation to succeed, but the generated binary to fail. I put up the project here along with the resulting (failing) test.prg binary. Maybe that can shed some light on things.

[mlund]

Thanks, @sagacity, I have similar issues when using mos-hardware as a dependency.

[mlund]

@sagacity It seems the problem may come from itertools iproduct, see #18. Could you try to change the optimization level from s to 2 or 3 in Cargo.toml?

[mrk-its]

@mlund can we close it? Can you verify that all examples in mos-hardware work now?

[mlund]

Everything ok!

[mrk-its]

Great!