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
