Closed lschuermann closed 1 year ago
bors r+
IDK if Bors still works atm, we'll see.
Build succeeded!
The publicly hosted instance of bors-ng is deprecated and will go away soon.
If you want to self-host your own instance, instructions are here. For more help, visit the forum.
If you want to switch to GitHub's built-in merge queue, visit their help page.
make raspberry_pi_pico EXAMPLE=console
LIBTOCK_PLATFORM=raspberry_pi_pico cargo run --example console \
--target=thumbv6m-none-eabi --release
Compiling libtock v0.1.0 (/Users/bradjc/git/libtock-rs)
error: linking with `rust-lld` failed: exit status: 1
|
= note: "rust-lld" "-flavor" "gnu" "/var/folders/_4/n3tmwxks3318tsb36d913f600000gn/T/rustcCgQTDB/symbols.o" "/Users/bradjc/git/libtock-rs/target/thumbv6m-none-eabi/release/examples/console-b8d0ccdcc2019f4a.console.958763e2-cgu.0.rcgu.o" "--as-needed" "-L" "/Users/bradjc/git/libtock-rs/target/thumbv6m-none-eabi/release/deps" "-L" "/Users/bradjc/git/libtock-rs/target/release/deps" "-L" "/Users/bradjc/git/libtock-rs/target/thumbv6m-none-eabi/release/build/libtock_runtime-99ba9d61b296ff5e/out" "-L" "/Users/bradjc/.rustup/toolchains/nightly-2022-06-10-x86_64-apple-darwin/lib/rustlib/thumbv6m-none-eabi/lib" "--start-group" "--end-group" "-Bstatic" "/Users/bradjc/.rustup/toolchains/nightly-2022-06-10-x86_64-apple-darwin/lib/rustlib/thumbv6m-none-eabi/lib/libcompiler_builtins-be4ad9a9d51b230c.rlib" "-Bdynamic" "--eh-frame-hdr" "-znoexecstack" "-L" "/Users/bradjc/.rustup/toolchains/nightly-2022-06-10-x86_64-apple-darwin/lib/rustlib/thumbv6m-none-eabi/lib" "-o" "/Users/bradjc/git/libtock-rs/target/thumbv6m-none-eabi/release/examples/console-b8d0ccdcc2019f4a" "--gc-sections" "-O1" "-Tlayout.ld"
= note: rust-lld: error:
Start of RAM region must be well-aligned to a 4kB boundary for LLVM's lld to
work. Refer to https://github.com/tock/libtock-rs/pull/477 for more
information. Set LIBTOCKRS_OVERRIDE_RAM_ORIGIN_CHECK = 1 to override this check
(e.g., when using a different linker).
rust-lld: error:
Start of RAM region must be well-aligned to a 4kB boundary for LLVM's lld to
work. Refer to https://github.com/tock/libtock-rs/pull/477 for more
information. Set LIBTOCKRS_OVERRIDE_RAM_ORIGIN_CHECK = 1 to override this check
(e.g., when using a different linker).
error: could not compile `libtock` due to previous error
make: *** [raspberry_pi_pico] Error 101
What do I do?
@bradjc Merge #476. That fixes this issue.
Rust's default linker (llvm-ld) as used with the Rust toolchain versions of at least
2022-06-10
,2023-01-26
, and2023-06-27
can produce broken ELF binaries when the RAM region's start address is not well-aligned to a 4kB boundary. Unfortunately, this behavior is rather tricky to debug: instead of refusing to produce a binary or producing a corrupt output, it generates an ELF file which includes a segment that points to the ELF file's header itself. elf2tab will include this segment in the final binary (as it is set to be loaded), producing broken TBFs. This (overrideable) check is designed to warn users that the linker may be misbehaved under these conditions.To reproduce this on this current git revision, with a Rust toolchain version
2023-06-27
, change theopentitan.ld
layout file to add an offset of 0x800 bytes to the RAM segment's start address:Further, remove the
.tbf_header
reservation:Now, compile the
console
example for theopentitan
target. When looking at the generated ELF file, it contains a segment at (an ELF-file) offset0x000000
, set to beLOAD
ed, with a non-zero size. This segment thus points to the ELF file header itself.When switching to the GNU LD instead, we get a correct ELF file. For that, make the following change to
.cargo/config
:Further, change the
.start
section's alignment, as GNU LD does not support specifying a section alignment constraint without a preceding section:This is the segment layout of the resulting binary, which is correct and no longer references the ELF header itself:
(In this case, the .stack section is included in the final binary in a segment of size
0x900
, to account for the segment alignment constraints. This also points to the ELF-internal offset of0x000000
, so referencing the ELF header. Yet this is fine in this case, as the.stack
symbol within that region is beyond the allocatedMemSiz
offset (at an offset of0x800
), so zero-initialized as intended. The.stack
should not at all end in the final binary, and never at aPhysAddr
/ load address within the RAM section; however this is an orthogonal issue.)