Recent nightly versions break thumb* targets

[jamesmunns]

Hey all,

I've noticed in nightly-2019-07-18, rustc has begun producing symbols in the .ARM.exidx region, which it did not previously do. As our standard linker script does not have a linker rule for this region, building fails with with the following error:

  = note: rust-lld: error: no memory region specified for section '.ARM.exidx'

To reproduce this, this project can be used: https://github.com/ferrous-systems/embedded-trainings/tree/master/beginner/templates/segment-1. You will need to add the thumbv7em-none-eabihf target first. This builds with the current and previous stable releases (1.32 <= version <= 1.36), but does not build with nightly-2019-07-18. This also seems fine with rustc 1.37.0-beta.3 (2ba6de7 2019-07-12). I have not yet attempted to bisect this.

We've had a previous similar issue here: rust-embedded/cortex-m-rt#157 - and the fix was to discard that section in our linker script template. However I first wanted to check if this new output was expected, because it would cause a stable to stable regression if folks don't update the cortex-m-rt crate, which includes the linker script template.

[jamesmunns]

Bisecting, this behavior showed up between:

• nightly-2019-07-17 - rustc 1.38.0-nightly (07e0c36 2019-07-16) - OK
• nightly-2019-07-18 - rustc 1.38.0-nightly (bc2e84c 2019-07-17) - NOT OK

EDIT:

link to diff of commits

[jonas-schievink]

Possibly caused by the LLVM update in #62592 – cc @nikic

It seems unexpected to me that this section is now included, since embedded projects are built with panic = abort

[nikic]

Based on https://lists.llvm.org/pipermail/llvm-dev/2019-March/130669.html it seems like the emission of .ARM.exidx is by design, even if no unwinding is used and the suggestion there is to discard in the linker.

[nikomatsakis]

Update from compiler team triage:

I can't tell quite what's going on here. Is this a compiler bug or something to be fixed downstream? @nikic's comment suggests the latter -- @jamesmunns if that is true, can you close the issue?

[nikomatsakis]

Marking as P-high so we check up on this

[jamesmunns]

So in general:

• This does appear to be an expected change in LLVM9
  • It's not a bug, just not something that was emitted by rustc/llvm before, so we have no handling for this section in our linker scripts
• Current versions of widely (nearly universally) used crates that are fundamental for embedded systems (e.g. cortex-m-rt, which provides a linker script generation template, among other things) do not handle this change, and are broken by versions of rustc that include LLVM9.
• We have submitted and landed a PR to cortex-m-rt to handle this (updating the linker script template we use), but have not yet released an updated crate for this
  • EDIT: We have tagged a release candidate as of 2019-07-25, but have not yet published on crates.io.
• Users will experience broken builds with confusing errors if they update from stable to stable, unless they also update their version of cortex-m-rt, once an update has been released.

This is an odd case, since I suppose the list of linker sections produced by rustc isn't really a "stabilized decision", but this will be mildly annoying for embedded users. I'd say our best handling responses to this would be:

• Find a way to disable this section when abort = panic, either through Rust or configuration of LLVM9
  • It is unclear if this is possible at all
• Patch LLVM to not emit .ARM.exidx sections when abort = panic
  • This has an unknown, and likely unfortunate amount of effort associated with it
• Do some kind of post-processing (invocation flags to LLD maybe?) to prevent this from happening
  • No idea if this is possible
• Deal with the breakage, do our best to put out information that upgrades to cortex-m-rt will be needed, hopefully making the fix searchable, and the knowledge well-known before LLVM9 lands in stable.
  • Annoying stable-to-stable regression for embedded users