On 10/04/2019 10:16, Christophe Lyon wrote: > On Wed, 10 Apr 2019 at 00:30, Richard Earnshaw > <richard.earns...@foss.arm.com> wrote: >> >> On 09/04/2019 13:26, Christophe Lyon wrote: >>> Hi, >>> >>> While building a newlib-based arm-eabi toolchain with >>> --with-multilib-list=rmprofile, I faced a linker assertion failure in >>> elf32_arm_merge_eabi_attributes (bfd/elf32-arm.c): >>> BFD_ASSERT (in_attr[Tag_ABI_HardFP_use].i == 0) >>> >>> I traced this down to newlib's impure.o containing only data, and thus >>> GCC does not emit a .fpu directive when compiling impure.c. >>> >>> When the linker merges impure.o's attributes with the other >>> contributions that already have >>> Tag_FP_arch, this assertion fails because in my multilib case (-mthumb >>> -march=armv7e-m+fp -mfloat-abi=softfp) all the object files have >>> Tag_ABI_HardFP_use: SP only >>> >>> Put differently, all objects but impure.o have >>> Tag_ABI_HardFP_use: SP only >>> Tag_FP_arch: VFPv4-D16 >>> but impure.o has only: >>> Tag_ABI_HardFP_use: SP only >>> (and no Tag_FP_arch) >>> >>> Removing the linker assertion makes the build succeed, so I guess my >>> question is: should I submit a linker patch to remove the assert >>> because it is too strict, or should I find a way to make GCC emit the >>> needed .fpu directive? >>> >>> Thanks, >>> >>> Christophe >>> >> >> I think removing the assert will remove entirely the check that a user >> is not mixing code with incompatible ABIs. So probably this is a bug. >> >> Which version of GCC were you using, and which version of binutils? I >> thought I'd addressed this when doing the rework of the FPU option code; >> but perhaps I've missed something somewhere. I'll check in more detail >> tomorrow. >> > > This was with binutils-2.28-branch from Apr 11th, 2017 and GCC trunk > from Nov 15th, 2018 (r266188), newlib master from Apr 1st 2019. > > However, upgrading to binutils master avoided the problem. > > Thanks, > > Christophe >
Digging through the archives it does look as though I reached the same conclusion as you did: that the assert is too harsh. The patch was this one: https://sourceware.org/ml/binutils/2017-06/msg00090.html R.
