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

mindstorm38 · 2020-12-20T13:37:58Z

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.

The text was updated successfully, but these errors were encountered:

adamgreig · 2020-12-21T00:41:48Z

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 · 2020-12-21T23:21:10Z

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 · 2021-01-25T11:49:54Z

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 · 2021-01-25T12:29:26Z

Great job, nice!

Robert-Cunningham · 2021-04-11T00:42:17Z

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 · 2021-04-11T00:44:35Z

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

adamgreig · 2021-04-11T00:46:42Z

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.

310: Only emit link_section for cortex-m r=jonas-schievink a=adamgreig Previously we always emitted `link_section`, even though it only had an effect when our linker script was being used (and only made sense on cortex-m targets). This breaks building the code for a MacOS target, which is occasionally useful for running `cargo check` etc. In the macros crate we don't have the target information available, so instead we continue to emit `link_section` except specifically on MacOS. This keeps the fix from #306 but hopefully resolves the confusion in rust-embedded/cortex-m-rt#74 (comment). Co-authored-by: Adam Greig <[email protected]>

adamgreig closed this as completed Jan 25, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

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

mindstorm38 commented Dec 20, 2020 •

edited

Loading

adamgreig commented Dec 21, 2020

Uh oh!

mindstorm38 commented Dec 21, 2020

Uh oh!

adamgreig commented Jan 25, 2021

Uh oh!

mindstorm38 commented Jan 25, 2021

Uh oh!

Robert-Cunningham commented Apr 11, 2021 •

edited

Loading

Uh oh!

Robert-Cunningham commented Apr 11, 2021

Uh oh!

adamgreig commented Apr 11, 2021

Uh oh!

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

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

Comments

mindstorm38 commented Dec 20, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

adamgreig commented Dec 21, 2020

Uh oh!

mindstorm38 commented Dec 21, 2020

Uh oh!

adamgreig commented Jan 25, 2021

Uh oh!

mindstorm38 commented Jan 25, 2021

Uh oh!

Robert-Cunningham commented Apr 11, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Robert-Cunningham commented Apr 11, 2021

Uh oh!

adamgreig commented Apr 11, 2021

Uh oh!

mindstorm38 commented Dec 20, 2020 •

edited

Loading

Robert-Cunningham commented Apr 11, 2021 •

edited

Loading