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. R.
