Re: [arm] Too strict linker assert?

[Richard Earnshaw <Richard.Earnshaw@foss.arm.com>]

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.