[Impact]
This bug prevents users to produce binaries for some of the targets supported by the compiler. In some case, binaries can get produced but will fail to execute properly.
To fix this issue the package needs to be rebuilt from the same source. Risk of regressions are thus limited to an issue in the arm-none-eabi toolchain used for the rebuild.
The bug stems from newlib having libraries for various targets (called multilib) in a different location than where the compiler expects them to be, thus making the wrong libraries get selected. The location of the newlib libraries is decided at build time by asking the compiler (provided in gcc-arm-none-eabi) where it will be looking for these. Unfortunately, the version of newlib in Ubuntu bionic was built using a different version of gcc-arm-none-eabi than the one currently in bionic and GCC changed where to look for library between those 2 versions. This is why rebuilding against the current gcc-arm-none-eabi will solve the issue.
[Test Case]
Compile the following hello world testcase (in hello.c) with arm-none-eabi-gcc -o hello.axf hello.c -mthumb -Wl,--gc-sections -ffast-math -march=armv7e-m -specs=rdimon.specs
#include <stdio.h>
int
main (void)
{
puts ("Hello, World!");
return 0;
}
[Regression Potential]
As explained in the impact, no source change is necessary so any regression would be due to bugs in the compiler which would be good to catch anyway.
Original bug report below:
The multilib setup is not working in the bionic version of gcc-arm-none-eabi (gcc v6.3.1). For example, if I build a project with "-mcpu=cortex-m4" or "-march=armv7e-m" and link with:
arm-none-eabi-gcc -o someoutput.elf object1.o object2.o -mthumb -Wl,--gc-sections -ffast-math -march=armv7-m -Tlinker_script.ld
I get as output:
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error: /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o: Conflicting CPU architectures 13/1
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o
arm-none-eabi-readelf -A on any of my object files produces:
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "Cortex-M4"
Tag_CPU_arch: v7E-M
Tag_CPU_arch_profile: Microcontroller
Tag_THUMB_ISA_use: Thumb-2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_number_model: Finite
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: small
Tag_ABI_optimization_goals: Prefer Speed
Tag_CPU_unaligned_access: v6
But "arm-none-eabi-readelf -A /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o" gives
Attribute Section: aeabi
File Attributes
Tag_CPU_arch: v4
Tag_ARM_ISA_use: Yes
If I define "void _init(void){}" and use -nostartfiles, compilation finishes but the resulting binary does not work. I have not examined the output file but it appears that it has somehow linked to code containing ARM as well as thumb code:
# readelf -A someoutput.elf
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "Cortex-M4"
Tag_CPU_arch: v7E-M
Tag_CPU_arch_profile: Microcontroller
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: small
Tag_ABI_optimization_goals: Prefer Speed
Tag_CPU_unaligned_access: v6
I can work around the problem by manually specifying compatible versions of libc and libgcc with -nostdlib:
-nostdlib /usr/lib/arm-none-eabi/newlib/thumb/libc.a /usr/lib/gcc/arm-none-eabi/6.3.1/thumb/v7e-m/libgcc.a
This produces a working binary. However, there is still something wrong because readelf -A still includes "Tag_ARM_ISA_use: Yes":
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "Cortex-M4"
Tag_CPU_arch: v7E-M
Tag_CPU_arch_profile: Microcontroller
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: small
Tag_ABI_optimization_goals: Prefer Speed
Tag_CPU_unaligned_access: v6
Previously, using xenial and gcc v4, readelf gives the following output on the output binary:
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7E-M"
Tag_CPU_arch: v7E-M
Tag_CPU_arch_profile: Microcontroller
Tag_THUMB_ISA_use: Thumb-2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: small
Tag_ABI_optimization_goals: Prefer Speed
Tag_CPU_unaligned_access: v6
(Also, what happened to gdb-arm-none-eabi?)
Note: I do not think it is an upstream problem, since I downloaded gcc-arm-