[arm] Too strict linker assert?

[arm] Too strict linker assert?

[Christophe Lyon]

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

Re: [arm] Too strict linker assert?

[Richard Earnshaw]

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.

Re: [arm] Too strict linker assert?

[Christophe Lyon]

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

Re: [arm] Too strict linker assert?

[Richard Earnshaw (lists)]

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.

Re: [arm] Too strict linker assert?

[Christophe Lyon]

On Wed, 10 Apr 2019 at 11:42, Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> 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
>

Ha, thanks for the pointer, and sorry for the noise.

Christophe