Version 0.7.0 : Failed to load bc of "cortex_m-[...].cortex_m.[...]-cgu.0.rcgu.o"

[mindstorm38]

Hello, I've recently found a critical issue that prevent a project using cortex-m version 0.7.0 from being linked (at least on my computer).
Because I'm a newbie in embedded software, to reproduce this issue I downloaded the cortex-m-quickstart. My conclusion is that the only parameter that allow the example project to build and not mine is the cortex-m version (0.6.0 works but 0.7.0 don't).

Some more context:

• os Windows 10
• rustc 1.48.0 (7eac88abb 2020-11-16)
• target arch thumbv7em-none-eabihf
• target microproc stm32f303k8

Memory mapping (memory.x):

MEMORY
{
  FLASH : ORIGIN = 0x08000000, LENGTH = 64K
  RAM : ORIGIN = 0x20000000, LENGTH = 12K
}

Linker error trace:

warning: Linking globals named 'CORE_PERIPHERALS': symbol multiply defined!
error: failed to load bc of "cortex_m-e7808f4bc8bc3911.cortex_m.a36est71-cgu.0.rcgu.o": 
error: aborting due to previous error; 3 warnings emitted
error: could not compile `rust-cortex-m`

Update(s):

• Version 0.6.4 also link correctly.

Maybe an idea:
Can this be caused by the fact that cortex-m-rt only use cortex-m version 0.6.*? Could this cause the two versions to define the symbol? In this case it can be a great addition for beginners to add a warning message explaining that two or more version of cortex-m can't coexist.

[adamgreig]

Hi, thanks for reporting!

As you identified, the problem is having multiple versions of cortex-m in one project, which can't co-exist. In fact, cortex-m-rt does not depend on cortex-m, but probably another crate you are using (perhaps stm32f3 for your MCU?) probably does depend on an older version of cortex-m.

We added a warning message in cortex-m v0.6.1 (using the Cargo links feature) so that it will tell the user about this, but that didn't exist in version v0.6.0, and my guess is your build pulled in 0.6.0 and 0.7.0, so the warning isn't able to detect the conflict. It would be good to confirm that though - please could you paste the output of cargo tree?

Right now, it will be required that the PACs such as stm32f3 upgrade to use cortex-m 0.7 first, before it's possible to also use 0.7 in your own applications. We might be able to make them work together with a new 0.6.5 release, but that's still being looked at. For the time being, you should probably just keep using the 0.6.4 version.

[mindstorm38]

Yes it's stm32f3xx-hal (and stm32f3, instead of cortex-m-rt).

The tree (with cortex-m = "0.7.0") :

├── cortex-m v0.7.0
│   ├── bare-metal v0.2.5
│   │   [build-dependencies]
│   │   └── rustc_version v0.2.3
│   │       └── semver v0.9.0
│   │           └── semver-parser v0.7.0
│   ├── bitfield v0.13.2
│   ├── embedded-hal v0.2.4
│   │   ├── nb v0.1.3
│   │   │   └── nb v1.0.0
│   │   └── void v1.0.2
│   └── volatile-register v0.2.0
│       └── vcell v0.1.2
├── cortex-m-rt v0.6.13
│   ├── cortex-m-rt-macros v0.1.8
│   │   ├── proc-macro2 v1.0.24
│   │   │   └── unicode-xid v0.2.1
│   │   ├── quote v1.0.7
│   │   │   └── proc-macro2 v1.0.24 (*)
│   │   └── syn v1.0.54
│   │       ├── proc-macro2 v1.0.24 (*)
│   │       ├── quote v1.0.7 (*)
│   │       └── unicode-xid v0.2.1
│   └── r0 v0.2.2
├── cortex-m-semihosting v0.3.7
│   └── cortex-m v0.7.0 (*)
├── embedded-hal v0.2.4 (*)
├── panic-halt v0.2.0
└── stm32f3xx-hal v0.6.0
    ├── bare-metal v0.2.5 (*)
    ├── cfg-if v1.0.0
    ├── cortex-m v0.6.0
    │   ├── aligned v0.3.4
    │   │   └── as-slice v0.1.4
    │   │       ├── generic-array v0.12.3
    │   │       │   └── typenum v1.12.0
    │   │       ├── generic-array v0.13.2
    │   │       │   └── typenum v1.12.0
    │   │       ├── generic-array v0.14.4
    │   │       │   └── typenum v1.12.0
    │   │       │   [build-dependencies]
    │   │       │   └── version_check v0.9.2
    │   │       └── stable_deref_trait v1.2.0
    │   ├── bare-metal v0.2.5 (*)
    │   └── volatile-register v0.2.0 (*)
    ├── cortex-m-rt v0.6.13 (*)
    ├── doc-comment v0.3.3
    ├── embedded-dma v0.1.2
    │   └── stable_deref_trait v1.2.0
    ├── embedded-hal v0.2.4 (*)
    ├── nb v0.1.3 (*)
    ├── paste v1.0.4
    ├── rtcc v0.2.0
    │   └── chrono v0.4.19
    │       ├── num-integer v0.1.44
    │       │   └── num-traits v0.2.14
    │       │       [build-dependencies]
    │       │       └── autocfg v1.0.1
    │       │   [build-dependencies]
    │       │   └── autocfg v1.0.1
    │       └── num-traits v0.2.14 (*)
    ├── stm32f3 v0.12.1
    │   ├── bare-metal v0.2.5 (*)
    │   ├── cortex-m v0.6.0 (*)
    │   ├── cortex-m-rt v0.6.13 (*)
    │   └── vcell v0.1.2
    └── void v1.0.2

[adamgreig]

We've now released 0.6.5, so this issue should be resolved - you can build with both 0.6 and 0.7 series crates in the same project. You may need to run cargo update to pull in the new version. Let us know if there's still any issues!

[mindstorm38]

Great job, nice!

[Robert-Cunningham]

Hi, @adamgreig! Unfortunately I'm running into this same issue. Below is my memory.x and the result of cargo tree (only >0.6.5 or 0.7.x versions of cortex-m).

controller-2007 v0.1.0 (/home/robert/Documents/Embedded/controller-2007)
├── cortex-m v0.7.2
│   ├── bare-metal v0.2.5
│   │   [build-dependencies]
│   │   └── rustc_version v0.2.3
│   │       └── semver v0.9.0
│   │           └── semver-parser v0.7.0
│   ├── bitfield v0.13.2
│   ├── embedded-hal v0.2.4
│   │   ├── nb v0.1.3
│   │   │   └── nb v1.0.0
│   │   └── void v1.0.2
│   └── volatile-register v0.2.0
│       └── vcell v0.1.3
├── cortex-m-rt v0.6.13
│   ├── cortex-m-rt-macros v0.1.8 (proc-macro)
│   │   ├── proc-macro2 v1.0.26
│   │   │   └── unicode-xid v0.2.1
│   │   ├── quote v1.0.9
│   │   │   └── proc-macro2 v1.0.26 (*)
│   │   └── syn v1.0.69
│   │       ├── proc-macro2 v1.0.26 (*)
│   │       ├── quote v1.0.9 (*)
│   │       └── unicode-xid v0.2.1
│   └── r0 v0.2.2
├── cortex-m-semihosting v0.3.7
│   └── cortex-m v0.7.2 (*)
├── drogue-mpu-6050 v0.1.1 (/home/robert/Documents/Embedded/libraries/drogue-mpu-6050)
│   ├── embedded-hal v0.2.4 (*)
│   ├── libm v0.2.1
│   └── log v0.4.14
│       └── cfg-if v1.0.0
├── panic-halt v0.2.0
├── stm32f3 v0.13.0
│   ├── bare-metal v0.2.5 (*)
│   ├── cortex-m v0.7.2 (*)
│   ├── cortex-m-rt v0.6.13 (*)
│   └── vcell v0.1.3
└── stm32f3xx-hal v0.6.1
    ├── bare-metal v0.2.5 (*)
    ├── cfg-if v1.0.0
    ├── cortex-m v0.6.7
    │   ├── aligned v0.3.4
    │   │   └── as-slice v0.1.5
    │   │       ├── generic-array v0.12.4
    │   │       │   └── typenum v1.13.0
    │   │       ├── generic-array v0.13.3
    │   │       │   └── typenum v1.13.0
    │   │       ├── generic-array v0.14.4
    │   │       │   └── typenum v1.13.0
    │   │       │   [build-dependencies]
    │   │       │   └── version_check v0.9.3
    │   │       └── stable_deref_trait v1.2.0
    │   ├── bare-metal v0.2.5 (*)
    │   ├── bitfield v0.13.2
    │   ├── cortex-m v0.7.2 (*)
    │   └── volatile-register v0.2.0 (*)
    ├── cortex-m-rt v0.6.13 (*)
    ├── embedded-dma v0.1.2
    │   └── stable_deref_trait v1.2.0
    ├── embedded-hal v0.2.4 (*)
    ├── nb v0.1.3 (*)
    ├── paste v1.0.5 (proc-macro)
    ├── rtcc v0.2.0
    │   └── chrono v0.4.19
    │       ├── num-integer v0.1.44
    │       │   └── num-traits v0.2.14
    │       │       [build-dependencies]
    │       │       └── autocfg v1.0.1
    │       │   [build-dependencies]
    │       │   └── autocfg v1.0.1
    │       └── num-traits v0.2.14 (*)
    ├── stm32f3 v0.12.1
    │   ├── bare-metal v0.2.5 (*)
    │   ├── cortex-m v0.6.7 (*)
    │   └── vcell v0.1.3
    └── void v1.0.2

{
  FLASH : ORIGIN = 0x08000000, LENGTH = 32K
  RAM : ORIGIN = 0x20000000, LENGTH = 16K
}

warning: Linking globals named 'DEVICE_PERIPHERALS': symbol multiply defined!

error: failed to load bc of "stm32f3-8ef371e8acf4c2b2.stm32f3.c92jmf7y-cgu.0.rcgu.o":

Let me know if there's any other way I can help.

[Robert-Cunningham]

For anyone else seeing this issue from Google: Removing the dependency on stm32f3 works as a band aid fix.

[adamgreig]

warning: Linking globals named 'DEVICE_PERIPHERALS': symbol multiply defined!

This looks like a slightly different error - instead of PERIPHERALS, which comes from cortex-m, you have DEVICE_PERIPHERALS multiply defined, which comes from your PAC. In this case stm32f3 v0.13 that you depend on directly is conflicting with stm32f3 v0.12.1 from stm32f3xx-hal. The only options are to depend on stm32f3 v0.12.1 yourself, or to patch the HAL to depend on the newer version. It's the same core problem (both cortex-m and stm32f3 need to be sure they only exist "once" to prevent multiple access to peripherals), but in this case nothing to do with cortex-m itself.