Hi Matthias,

The issue, as I understand it, is that crti.o has a Tag_ABI_HardFP attribute set
, but no Tag_FP_arch set.  So this results in the initial output file having the same settings.  Then crtbeginS.o is processed and this has a Tag_FP_arch set but no Tag_ABI_HardFP.  So the assertion is triggered as you have seen.

Assuming that the comment in the code is correct then it looks like the crti.o file might be broken.  Ie it should have both of those tags defined (or neither of them).  Is the file produced from assembler source code or is it compiled ?

Cheers
  Nick

Yes, the attributes on crti.o are not as expected, but the reading process should sanitize them in that case, and if really broken emit a sensible user diagnostic.  It should not generate an assertion failure at the point where it does.

The correct fix, I think, is to convert the value 3 into value zero when reading the input object.  This converts the deprecated value into the expected replacement.

Created attachment 13968 [details]
Proposed Patch

Hi Richard,

  How about this patch ?

  I was unsure what should be done with the other potential values 
  for Tag_ABI_HardFP_use so I left them alone.

Cheers
  Nick

*** Bug 28859 has been marked as a duplicate of this bug. ***

(In reply to Nick Clifton from comment #3)
> Created attachment 13968 [details]
> Proposed Patch
> 
> Hi Richard,
> 
>   How about this patch ?
> 
>   I was unsure what should be done with the other potential values 
>   for Tag_ABI_HardFP_use so I left them alone.
> 
> Cheers
>   Nick

I need to think about this a bit.  The object file is arguably buggy in that it says that it uses hw fp, but doesn't say which version.  But if we report an error (or a warning) we probably should do that for all input objects, not just the first on the list.

Also, if we agree the object is buggy, we should probably have code in the assembler to fault that when the object is created.  We should also warn if a deprecated tag value is picked, though I'm a little worried that might cause problems with version skew when used with older GCC releases - but perhaps tsktsk is good enough.

(In reply to Richard Earnshaw from comment #5)

> I need to think about this a bit.  The object file is arguably buggy in that
> it says that it uses hw fp, but doesn't say which version.  But if we report
> an error (or a warning) we probably should do that for all input objects,
> not just the first on the list.

Given that the value of 3 for Tag_ABI_HardFP_use is deprecated, that would
be reasonable.


> Also, if we agree the object is buggy, we should probably have code in the
> assembler to fault that when the object is created.  We should also warn if
> a deprecated tag value is picked, though I'm a little worried that might
> cause problems with version skew when used with older GCC releases - but
> perhaps tsktsk is good enough.

Fair enough.  The thing that worries me is that the problematic file - crti.o - comes from glibc and is going to affect the building of a lot of projects.  So whilst glibc can be fixed, that will take some time, and in the meantime other peoples projects are stuck.  A solution which will allow builds to complete - even if it means ignoring a warning message from the linker, is probably preferable to triggering an assert.

(In reply to Nick Clifton from comment #6)

> Fair enough.  The thing that worries me is that the problematic file -
> crti.o - comes from glibc and is going to affect the building of a lot of
> projects.  So whilst glibc can be fixed, that will take some time, and in
> the meantime other peoples projects are stuck.  A solution which will allow
> builds to complete - even if it means ignoring a warning message from the
> linker, is probably preferable to triggering an assert.

It doesn't come from glibc, it comes from a debian-local patch to glibc, as I understand it.

that patch is
https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/arm/local-vfp-sysdeps.diff

Michael just confirmed that fpc still fails to build without this patch (and builds with the updated patch as suggested by Richard).

Hi.

I applied the patch proposed by Nick Clifton in Raspbian bookworm, that made glibc build, however I am still getting what I am 99% sure is the the same assertion (the line number has changed, but I'm pretty sure that is a result of the patch altering line numbers in the file) when I try to use fpc to build a program that links against libc.

As I understand it, freepascal uses it's own startup code. For pascal programs that do not link against C libaries there is a pascal only startup code (prt0.o) while for pascal programs that link against C libraies there is a "C and pascal" startup code.

The "C and pascal" startup code is stored in cprt0.o, which is built from cprt0.as there are different versions of that file for different architecture/os combinations, the arm linux one can be found at https://gitlab.com/freepascal.org/fpc/source/-/blob/main/rtl/linux/arm/cprt0.as

What I don't get is why things seem to be working on Debian armhf, at least for native builds, does the different arm version or the fact that Debian armhf uses thumb mode by default make a difference?

This may be a dup of PR 28903.

Doesn't seem related, this assert relates to arm tags (or the lack thereof), PR 28903 was about an issue on x86-64.

The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=81c9e0f6c48748f4b66fc3b13e12eb68735cf1f9

commit 81c9e0f6c48748f4b66fc3b13e12eb68735cf1f9
Author: Nick Clifton <nickc@redhat.com>
Date:   Tue Mar 1 09:51:59 2022 +0000

    Prevent an assertion from being triggered when linking an ARM object file with incorrectly set build attributes.
    
            PR 28848
            PR 28859
            * elf32-arm.c (elf32_arm_merge_eabi_attributes): If the first
            input bfd has a Tag_ABI_HardFP_use set to 3 but does not also have
            TAG_FP_arch set then reset the TAG_ABI_HardFP_use.

I'm assuming this one is fixed by Nick's patch