link error when building for debug, works with --release

[bootchk]

This works: xargo build --release --target thumbv7m-none-eabi -v
But without --release I get:

error: linking with arm-none-eabi-ld failed: exit code: 1
....
= note: arm-none-eabi-ld:
You must specify the exception handlers.
Create a non pub static variable with type
cortex_m::exception::Handlers and place it in the
'.rodata.exceptions' section. (cf. #[link_section]). Apply the
#[used] attribute to the variable to make it reach the linker.
arm-none-eabi-ld:
Invalid '.rodata.exceptions' section.
Make sure to place a static with type cortex_m::exception::Handlers
in that section (cf. #[link_section]) ONLY ONCE.

Same error as in your FAQ but different cause?

Rookie to rust. My dev environment is in a vagga container https://github.com/bootchk/rustDevContainers rustNordicBlinky. The container script follows your tutorial more or less, for Nordic nrf52832. I get a blinky.rs to compile and load to a NRF52DK board, but it doesn't blink yet.

[bootchk]

I see this is probably related to your PR about codegen units 32.

[japaric]

Fixed in cortex-m-rt v0.3.6. Affected users try cargo update.

[bootchk]

I completely rebuilt my vagga container (whose script follows the tutorial.) Now I get:

• "cargo" "build" "--release" "--manifest-path" "/tmp/xargo.2i7nVBhmkMAs/Cargo.toml" "--target" "thumbv7m-none-eabi" "-v" "-p" "compiler_builtins"
  error: no matching version = 0.0.0 found for package compiler_builtins (required by sysroot)
  location searched: file:///work/.home/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcompiler_builtins
  versions found: 0.1.0
  consider running cargo update to update a path dependency's locked version

For my commands:

echo Copied blinky.rs into project
cp blinky.rs demo/src/main.rs
cd demo
unset CARGO_INCREMENTAL
cargo clean
rm -rf ../.home/.xargo
cargo update
xargo build --target thumbv7m-none-eabi -v
arm-none-eabi-readelf -A target/thumbv7m-none-eabi/release/demo

?Related to rust-lang/cargo#4486

Again, I am rookie. Not sure when to do "cargo update" but if I rebuilt my container completely, I don't think I need it. My script for building the container (following the tutorial) could easily be flawed.

[japaric]

@bootchk Sorry about that. Xargo v0.3.9 can't compile compiler-builtins -- this is a regression cf. japaric/xargo#167. Please switch back to version v0.3.8. (the command for that is cargo install xargo --vers 0.3.8, IIRC)

[bootchk]

Now:

= note: arm-none-eabi-ld:
The interrupt handlers are missing. If you are not linking to a device
crate then you supply the interrupt handlers yourself. Check the
documentation.

I will check that I built my "nordic" device crate correctly.

Please let me know if my reports are premature. Thanks for your work.

[bootchk]

But the tail of my blinky.rs is:

`// This part is the same as before
#[allow(dead_code)]
#[used]
#[link_section = ".rodata.interrupts"]
static INTERRUPTS: [extern "C" fn(); 240] = [default_handler; 240];

extern "C" fn default_handler() {
asm::bkpt();
}`

Which I think is the interrupt handler for all interrupt vectors.

[japaric]

#[link_section = ".rodata.interrupts"]

The link section has been renamed to .vector_table.interrupts in cortex-m-rt v0.3.x. it was .rodata.interrupts in cortex-m-rt v0.2.x.

If you are linking to a device crate, a crate generated using svd2rust, make sure you are using the latest version of svd2rust with cortex-m-rt v0.3.x. The .vector_table.interrupts link section comes from that crate.

[bootchk]

Thanks, it compiles and links now. Sorry for using stale version.

FYI I also tried lld-5.0. It doesn't find link.x down in the dependencies, and chokes on link.x syntax (lld not quite compatible with gcc ld scripts yet).

[japaric]

FYI I also tried lld-5.0. It doesn't find link.x down in the dependencies, and chokes on link.x syntax (lld not quite compatible with gcc ld scripts yet).

Yeah, I know; I try lld every now and then. It would be great if lld had full support for ld-style linker scripts because we eventually (may) want to embed lld in rustc. If that happens then we wouldn't need arm-none-eabi-ld to link Cortex-M programs; we couild simply use the lld embedded in rustc.