I’m working on adding support for a new target. While building std, I stumbled across a bug in my backend’s support for cmpxchg with types smaller than 32 bits. I’ll work on fixing that next but I was hoping to work around the problem somehow for now. I want to either find the next bug or demo this to the team.
I tried turning off my target’s atomic_cas but it appears that the Sync trait has it as a critical dependency. Makes a lot of sense, I guess.
Is there a way to work around this dependency? Also, does the compiler generate sub-32 bit cmpxchg often enough that it would be useless to workaround this challenge?
You could compile your code to LLVM IR and rewrite it to get rid of the invalid cmpxchg’s. That might be more work than just fixing the codegen though.
Could I provide a null/minimal implementation of the Sync trait maybe? It would probably allow me to progress enough to find the next bug and demo lots of other non concurrency related features.
Turning off atomic_cas should work, and much more so should not have any interaction with the Sync trait. But it’s not possible to diagnose anything from the information you’ve proivided. Can you post the specific diff you’ve applied and the resulting build log and error messages?
Ohh, okay. Maybe the issue with Syncwas the next bug. I’ll look closer.
Sorry to report such incomplete info, not sure I could post the patch yet until I can convince the leadership to upstream it. I could probably sanitize the logs, though.
The problem when I set atomic_cas to false is not the Sync trait, but rather alloc_crate::sync. Sorry, I was too hasty when reading the build failure log.
I see now that there’s all(not(stage0), target_has_atomic = "ptr", target_has_atomic = "cas") in src/liballoc/lib.rs.
I see a relatively recent commit (683a3db01fcd00998a36e494ee39209b3105cfb9) changes the conditions here so I’ll update and try it again.
I see a relatively recent commit ( 683a3db01fcd00998a36e494ee39209b3105cfb9 ) changes the conditions here so I’ll update and try it again.
That commit didn't help, effectively bars !atomic_cas because sync.rs has code that depends on it. I'll see if there's a way to implement a nop version of atomic_compare_exchange*.
I was able to stub out the atomic compare exchange routines. Now I have a libstd that successfully built for my target, but the build fails during “Building stage 1 compiler artifacts”. It is trying to build the libc crate but cargo is picking the public libc from GH and not my local rust/src/liblibc one. The build failures are regarding c_char and other types that I defined in src/liblibc/src/unit/notbsd/linux/musl/b32/new_tgt.rs. I tried patching the src/cargo/Cargo.toml with a [patch.crates.io], but that wasn’t effective. I saw these same build failures during an earlier step before I patched src/liblibc.
Let me take a step back and sanity check my build process:
./x.py build -vv --stage 1 my_tgt.toml # this step is redundant if I do the next one?
./x.py build -vv --stage 2 my_tgt.toml
my_tgt.toml features nothing terribly out of the ordinary, I think – use-jemalloc=false for now. I’ve tried with and without extended=true with the hopes of fixing this and it doesn’t seem to.
I’ve patched the files below:
src/libunwind/lib.rs # different set of `link()` for this target
src/liblibc/src/unit/notbsd/linux/musl/mod.rs # pub use self::my_tgt::*;
src/liblibc/src/unit/notbsd/linux/musl/b32/mod.rs # target_arch="my_tgt" before "mod b32;pub use self::b32::*;"
src/liblibc/src/unit/notbsd/linux/musl/b32/new_tgt.rs # new for my target
src/librustc_target/spec/my_tgt.rs
src/libcore/sync/atomic.rs # basic impl of atomic cas
src/libcore/lib.rs
src/liballoc_system/lib.rs
src/libpanic_unwind/gcc.rs # unwind registers
src/libunwind/libunwind.rs # unwind private data size
I’ll see if I can share a detailed log, if it’ll help.
As an aside: when I do the stage 1 build, it fails during Building stage0 std artifacts (after it already does Building stage1 std artifacts for my target). It is using the bootstrap rustc to ask about this new target I’ve added. error: failed to run rustc to learn about target-specific information / ... Could not find specification for target "my-tgt-...." . But that seems like a bug with bootstrap/, maybe? It should expect that to fail when there’s a new target that’s missing from the bootstrap. Either that or I’m running the wrong x.py command?
In any case, if I ignore the failure and proceed with stage 2, I’m still able to get build/x86-unknown-linux-gnu/stage2/lib/rustlib/mytgt-.../lib/libstd-<hash>.so before I see that failure above.