-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Description
Using rust to compile for Arduino target, I'm see a lot of weird and random behaviors from compiler when making changes to profile and compiler setting. (I'm using avr-hal for uno, here's a sample)
As an example, if I use hmac-sha256
crate:
let h = hmac_sha256::HMAC::mac(b"hello", b"key"); // hmac for input "hello" with key "key"
print_hex_arr(" mac", &mut serial, &h);
let h = hmac_sha256::Hash::hash(b"hello"); // sha256 of "hello"
print_hex_arr("hash", &mut serial, &h);
I get different outputs depending on opt-level
and lto
, correct one is:
mac = 9307b3b915efb5171ff14d8cb55fbcc798c6c0ef1456d66ded1a6aa723a58b7b
hash = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
which I'm getting from opt-level=2
with both lto=true
and unspecified, however:
// opt-level = "s", lto = true
mac = d238e536e20f0b1b210644248134891454c20ad29c10f75756218b6ab8f5c17d
hash = 5f23619d4ed28dbf06d25969fa262384869011f4a44469c1eb38c50b15b01c4b
// opt-level = "z", lto = true
mac = 03942da43b5034c3f87f9652c4d569392f444af18c66a7c587db8065d4c79faf
hash = 5f23619d4ed28dbf06d25969fa262384869011f4a44469c1eb38c50b15b01c4b
// opt-level = "s | z", lto unspecified
mac = d238e536e20f0b1b210644248134891454c20ad29c10f75756218b6ab8f5c17d
hash = 5f23619d4ed28dbf06d25969fa262384869011f4a44469c1eb38c50b15b01c4b
not only that, even if I run fns from another crate, even with the working opt-level = 2
, I get incorrect output:
other_crate::do_something();
let h = hmac_sha256::Hash::hash(b"hello");
print_hex_arr("hash", &mut serial, &h);
has a wrong output and instead this works:
let h = hmac_sha256::Hash::hash(b"hello");
print_hex_arr("hash", &mut serial, &h);
other_crate::do_something();
before I compile a bug report at gcc, I want to make sure the fault is not at rust side. here's the final command that rustc is running to link the final elf:
$ avr-gcc -mmcu=atmega328p -Wl,--as-needed,--print-memory-usage,--detailed-mem-usage -fpack-struct -fshort-enums -Wstack-usage=20 -Wall -Wextra -fstack-usage /tmp/rustcsspEI5/symbols.o /project/target/avr-atmega328p/release/deps/arduino_lib-1e0b86c11d560d13.arduino_lib.9b917980-cgu.0.rcgu.o -Wl,--as-needed -L /project/target/avr-atmega328p/release/deps -L /project/target/release/deps -L . -L /home/usr/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/avr-atmega328p/lib -Wl,-Bstatic /project/target/avr-atmega328p/release/deps/libcompiler_builtins-4dcc5d36d44c3317.rlib -Wl,-Bdynamic -lgcc -Wl,-znoexecstack -L /home/usr/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/avr-atmega328p/lib -o /project/target/avr-atmega328p/release/deps/arduino_lib-1e0b86c11d560d13.elf -Wl,--gc-sections -Wl,-O1 -Wl,--strip-all
as you can see it's using -O1
which I haven't specified anywhere. (See avr-atmega328p.json)
I have tried overriding in my avr-atmega328p.json file inside pre-link-args
but that doesn't affect anything. Can someone shed some light on what is going wrong here? If it's the -O1
flag, how do I override that?
Activity
saethlin commentedon Mar 11, 2023
We have some history with AVR miscompilations, so just glancing at this issue my priors are that it is more likely than not that this is a bug somewhere in rustc/LLVM.
You've included a fair bit of information in here, but there's no reproducer that I can run to observe the bug. Can you provide a program (snippet or link to a repo/example) that demonstrates the bug, and precise instructions on how to compile it and observe the bug? It would be a great help if someone tackling this doesn't need to have any particular hardware on hand in order to observe the bug.
workingjubilee commentedon Mar 11, 2023
To add to saethlin's request for a reproducer:
An entire repo is often fine as a reproducer for AVR issues, even though it is usually not for other targets. Often the problem is either so vague that further minimization is futile (so it can't be minimized) or so glaring that further minimization is pointless (making it apparent at a glance at the Cargo.toml or something like that). In particular, a full repo can be desired because some common ecosystem dependencies have used unsound code recently and you may have included one of them in your dependency graph, so please check in your Cargo.lock when pushing the repo so I can see what exact versions of crates you resolved.
Also, for that repo, please include the exact rustc/cargo build commands you are using to produce this issue, ideally. A file in the repo listing all of them would not be too much detail.
xphoniex commentedon Mar 11, 2023
zipped file: avr-bug.zip
avr-atmega328p.json
.cargo/config.toml
Cargo.toml
rust-toolchain.toml
src/main.rs
xphoniex commentedon Mar 11, 2023
In order to run this you need both avr toolchain such as
avr-gcc
andqemu-system-avr
. In a terminal runcargo run -r
and in another:then try changing
opt-level
,lto
, and uncomment the other crate in themain.rs
, and the move code around. you should be able to re-produce the bugs.workingjubilee commentedon Mar 11, 2023
For future reference, creating and pushing a repo to GitHub or another host that I can clone with a single command would have been preferred over something that requires me to manually reconstruct the files inside a repository.
xphoniex commentedon Mar 11, 2023
You're right, added the zip file.
workingjubilee commentedon Mar 11, 2023
Hmm. I don't know, in that case! Fair enough?!
Thank you for the clear instructions, I will try to reproduce this soon.
Also you will want to update to a version of rustc of about February 19 or later, as an ABI fix for AVR targets was merged about then. It doesn't affect your visible source but it may affect your dependencies.
xphoniex commentedon May 30, 2023
polite bump. any updates on this?
39 remaining items