[Bug 1767223] Re: multilib selects wrong start files
Thomas Preud'homme
thomas.preudhomme at arm.com
Tue Dec 18 11:18:48 UTC 2018
@ubuntu-sru and @ubuntu-sponsors: would you mind doing a new upload of
this package to bionic using the same source as in the last build? This
bug will be solved by rebuilding from the same source using the gcc-arm-
none-eabi package currently in bionic.
Best regards.
** Description changed:
+ [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
+ 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
+ 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
+ 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
+ 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
+ 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?)
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1767223
Title:
multilib selects wrong start files
Status in newlib package in Ubuntu:
Confirmed
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/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?)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1767223/+subscriptions
More information about the Ubuntu-sponsors
mailing list