compiling for 32-bit arm targets

[lynaghk]

Hi @myrrlyn, thanks for this crate and blog post!

I'm a beginner bit-twiddler, so being able to access bits "normally" (instead of shifting and boolean ops) gives me a fighting chance for my project (parsing optical signals on an ARM microcontroller).

I've used the crate successfully for testing on my mac, but am unable to actually compile to to my microcontroller (an stm32f1 "black pill" / cortex m3; target = "thumbv7m-none-eabi"). I'm using:

bitvec = { url = "https://github.com/myrrlyn/bitvec", default-features = false, features = []}

and my lockfile shows I'm using bitvec 0.16.1. I believe the issue from a transitive dependency, radium:

   Compiling radium v0.2.0
error[E0432]: unresolved imports `core::sync::atomic::AtomicI64`, `core::sync::atomic::AtomicU64`
  --> /Users/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/radium-0.2.0/src/lib.rs:29:45
   |
29 |     self, AtomicBool, AtomicI16, AtomicI32, AtomicI64, AtomicI8, AtomicIsize, AtomicPtr, AtomicU16,
   |                                             ^^^^^^^^^ no `AtomicI64` in `sync::atomic`
30 |     AtomicU32, AtomicU64, AtomicU8, AtomicUsize, Ordering,
   |                ^^^^^^^^^ no `AtomicU64` in `sync::atomic`
   |
help: a similar name exists in the module
   |
29 |     self, AtomicBool, AtomicI16, AtomicI32, AtomicI8, AtomicI8, AtomicIsize, AtomicPtr, AtomicU16,
   |                                             ^^^^^^^^
help: a similar name exists in the module
   |
30 |     AtomicU32, AtomicU8, AtomicU8, AtomicUsize, Ordering,
   |                ^^^^^^^^

Looks like it's trying to import AtomicI64, but there's no such type on my 32-bit microcontroller.

Any suggestions for how we should try to untangle this? Perhaps we can:

• update bitvec so that it doesn't depend on radium?
• update radium to use Rust's feature flags and conditional compilation system to only import 64-bit types on the appropriate platforms?
• some other solution?

I haven't done much feature flag or no-std Rust development, but am open to learn and submit a patch if you can recommend a direction.

Thanks!

[myrrlyn]

So it turns out that the standard library conditionally manifests the atomic types based on the target_has_atomic test, which is not available on stable for libraries to use: https://github.com/rust-lang/rust/blob/a06baa56b95674fc626b3c3fd680d6a65357fe60/src/libcore/sync/atomic.rs#L2094-L2129

Since radium is developed and tested on x86_64, and not on other targets, we just didn't think to check the gates on these types. I've submitted a patch to radium that gates the use of Atomic*64 on target_pointer_width, as that is the closest proxy we have for detecting whether a target has atomically-available 64-bit regions. If it is accepted and published, I will update bitvec to use it.

For now, use this override in your project manifest:

# Cargo.toml

[patch.crates-io]
radium = { git = "https://github.com/myrrlyn/radium.git", commit = "f37e569" }

This ought to pull my patch of radium, which compiles and passes tests on i686-unknown-linux-gnu and compiles on thumbv7m-none-eabi. If you have any further issues relating to absent symbols with any part of the bitvec dependency tree, feel free to note them in this issue. It is a bug in bitvec as a project to fail to compile on any 32-bit or 64-bit target. I do not currently make any guarantees about performance on targets I do not personally have, but I will happily add them as needed.

[lynaghk]

Thanks for the quick reply and explanation of the fix, makes sense.

Unfortunately, I can't seem to override bitvec's version of radium with your patched one, since the former pins to 0.2 and the latter is at 0.3. Cargo gives me:

warning: unused manifest key: patch.crates-io.radium.commit
warning: Patch `radium v0.3.0 (https://github.com/myrrlyn/radium.git#f37e5698)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
   Compiling radium v0.2.0

Re: targets you don't have --- I'd be more than happy to buy you a few boards and programmers if you ever want to play around with stm32 microcontrollers. The stm32f1-based "blue pill" and "black pill" chinesium breakout boards became popular a few years back as an atmega/arduino alternative and stm sells official "nucleo" dev boards for pretty much their entire stm32 line. Just email me (kevin@keminglabs.com) a shipping address and any particular boards you want to check out.

[myrrlyn]

This is what I get for doing minimal-effort support work over Christmas, I guess.

When radium v0.3 is published to crates.io, I will issue an immediate patch release of bitvec (0.16.2).

[lynaghk]

No worries, hope you had a great holiday. I'm thrilled that you wrote such a nice library for everyone to use.

Once the bitvec patch release is up (on crates.io or github) I'll test compilation and close this issue.

[myrrlyn]

Commit 253143e47b62ca8fb83432abef26d5d6a32b7f7d (not currently on a tracked branch) is published to crates.io. I will incorporate it into trunk later.

[lynaghk]

Hi @myrrlyn Just wanted to follow up and confirm that everything is working properly on my ARM-based microcontroller. Thanks again for the great library!

[ketsuban]

I'm experiencing a regression on this bug when using version 0.19.0 or later with the target thumbv4t-none-eabi. Can you rule out the possibility that the target triple is at fault here?