Compiling embedded-hal v0.2.4
error: could not compile
process didn't exit successfully:
rustc --crate-name core --edition=2018 /home/froderick/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C panic=abort -C embed-bitcode=no -C metadata=ad26667fea11b055 -C extra-filename=-ad26667fea11b055 --out-dir /home/froderick/rust_arduino_blink/target/avr-atmega328p/release/deps --target /home/froderick/rust_arduino_blink/avr-atmega328p.json -Z force-unstable-if-unmarked -L dependency=/home/froderick/rust_arduino_blink/target/avr-atmega328p/release/deps -L dependency=/home/froderick/rust_arduino_blink/target/release/deps --cap-lints allow (signal: 11, SIGSEGV: invalid memory reference)
[profile.dev] panic = "abort" lto = true opt-level = "s" [profile.release] panic = "abort" lto = true opt-level = "s" codegen-units = 1 debug = true
"data-layout": "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8", "max-atomic-width": 8,
If operands do not fit into a single register, the compiler will automatically assign enough registers to hold the entire operand. In the assembler code you use %A0 to refer to the lowest byte of the first operand, %A1 to the lowest byte of the second operand and so on. The next byte of the first operand will be %B0, the next byte %C0 and so on. This also implies, that it is often neccessary to cast the type of an input operand to the desired size. A final problem may arise while using pointer register pairs. If you define an input operand "e" (ptr) and the compiler selects register Z (r30:r31), then %A0 refers to r30 and %B0 refers to r31. But both versions will fail during the assembly stage of the compiler, if you explicitely need Z, like in ld r24,Z If you write ld r24, %a0 with a lower case a following the percent sign, then the compiler will create the proper assembler line.
$ cargo build -Z build-std=core --target avr-unknown-gnu-atmega328 --release Compiling core v0.0.0 (/home/kazuki/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core) Compiling rustc-std-workspace-core v1.99.0 (/home/kazuki/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core) Compiling compiler_builtins v0.1.35 error: could not compile `core` Caused by: process didn't exit successfully: `rustc --crate-name core --edition=2018 /home/kazuki/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C metadata=2eed32a902465f17 -C extra-filename=-2eed32a902465f17 --out-dir /mnt/h/Projects/avr-playground/led-blink/rust/target/avr-unknown-gnu-atmega328/release/deps --target avr-unknown-gnu-atmega328 -Z force-unstable-if-unmarked -L dependency=/mnt/h/Projects/avr-playground/led-blink/rust/target/avr-unknown-gnu-atmega328/release/deps -L dependency=/mnt/h/Projects/avr-playground/led-blink/rust/target/release/deps --cap-lints allow` (signal: 11, SIGSEGV: invalid memory reference) warning: build failed, waiting for other jobs to finish... error: build failed
Yup. That’s because the relocation is invalid and you are jumping to the wrong place.
Hi, I am attempting to play around with async on AVR and I have come across the bug mentioned back in July around function pointers not working with llvm+AVR (thanks to @lights0123 for the super-useful blog post). I am wondering if there has been any progress made on this bug, or if there is an updated issue I could watch? I saw the original attempt had been abandoned
tunaxorhey there, sorry to bother, are there some arduino uno guides out there? I saw the repo in the avr org but felt quite lost by just staring at it
It is a good starting point for rust on the arduino-uno.