This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [arm] Too strict linker assert?
On 10/04/2019 10:16, Christophe Lyon wrote:
> 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
>
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
R.