This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [arm] Too strict linker assert?
On Wed, 10 Apr 2019 at 00:30, Richard Earnshaw
<Richard.Earnshaw@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