On Wed, 10 Apr 2019 at 11:42, Richard Earnshaw (lists) <richard.earns...@arm.com> wrote: > > 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 >
Ha, thanks for the pointer, and sorry for the noise. Christophe
