This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

LTO linker error with GNU Arm 10.3-2021.07

I have attempted to upgrade the toolchain on a project for a Cortex-M0+ that requires LTO to fit in flash. The project has built just fine up until now, but after upgrading to the latest 10.3-2021.07 version, the linking stage fails. Here's what the output looks like:

/tmp/cczekWsc.s: Assembler messages:
/tmp/cczekWsc.s:2262: Warning: ignoring changed section attributes for .data
/tmp/cczekWsc.s:2272: Warning: dwarf line number information for .data ignored
/tmp/cczekWsc.s:2277: Warning: dwarf line number information for .data ignored
(repeated hundreds of times)
/tmp/cczekWsc.s:61406: Error: leb128 operand is an undefined symbol: .LVU708
/tmp/cczekWsc.s:61407: Error: leb128 operand is an undefined symbol: .LVU708
/tmp/cczekWsc.s:61425: Error: leb128 operand is an undefined symbol: .LVU730
(also repeated hundred plus of times)

Has anyone seen anything like this before? I tried searching for help on this, but came up blank. I'm unsure about how I should even start approaching this as I was unable to even keep the temporary assembler output from the LTO process.

Parents
  • This seems related to this bugreport: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698

    The combination of placing functions in the .data section (typically flash operations which by nature can not run through XIP), LTO and generating debug information by passing -g to the compiler leads to confusion somewhere down the toolchain here. I guess the suspected culprit is probably the binutils assembler.

    My project builds just fine if I remove '-g' from the CFLAGS.

Reply
  • This seems related to this bugreport: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698

    The combination of placing functions in the .data section (typically flash operations which by nature can not run through XIP), LTO and generating debug information by passing -g to the compiler leads to confusion somewhere down the toolchain here. I guess the suspected culprit is probably the binutils assembler.

    My project builds just fine if I remove '-g' from the CFLAGS.

Children
No data