multilib selects wrong start files
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
newlib (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Bionic |
Fix Released
|
Medium
|
Simon Quigley |
Bug Description
[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/
/usr/lib/
arm-none-
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "Cortex-M4"
Tag_CPU_arch: v7E-M
Tag_CPU_
Tag_THUMB_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_CPU_
But "arm-none-
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_
Tag_ARM_ISA_use: Yes
Tag_THUMB_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_CPU_
I can work around the problem by manually specifying compatible versions of libc and libgcc with -nostdlib:
-nostdlib /usr/lib/
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_
Tag_ARM_ISA_use: Yes
Tag_THUMB_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_CPU_
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_
Tag_THUMB_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_ABI_
Tag_CPU_
(Also, what happened to gdb-arm-none-eabi?)
Changed in newlib (Ubuntu Bionic): | |
status: | New → Triaged |
Changed in newlib (Ubuntu Disco): | |
status: | Confirmed → New |
Changed in newlib (Ubuntu Bionic): | |
importance: | Undecided → Medium |
Changed in newlib (Ubuntu Cosmic): | |
importance: | Undecided → Medium |
Changed in newlib (Ubuntu Disco): | |
importance: | Undecided → Medium |
tags: |
added: verification-failed-bionic removed: verification-needed-bionic |
Changed in newlib (Ubuntu): | |
status: | Confirmed → Fix Released |
no longer affects: | newlib (Ubuntu Cosmic) |
no longer affects: | newlib (Ubuntu Disco) |
Changed in newlib (Ubuntu Bionic): | |
status: | Fix Committed → Triaged |
tags: | removed: verification-needed |
Note: I do not think it is an upstream problem, since I downloaded gcc-arm- none-eabi- 6-2017- q2-update from ARM which contains a very similar version (both 6.3.1 20170620) and it does not exhibit the issue.