[Bug target/124365] New: -flto -g loses AEABI attributes on aarch64 when configured against recent binutils

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124365

            Bug ID: 124365
           Summary: -flto -g loses AEABI attributes on aarch64 when
                    configured against recent binutils
           Product: gcc
           Version: 16.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

When gcc is configured against recent binutils (e.g. 2.46), it uses e.g. for -S
-g -mbranch-protection=standard
        .aeabi_subsection aeabi_feature_and_bits, optional, ULEB128
        .aeabi_attribute Tag_Feature_BTI, 1
        .aeabi_attribute Tag_Feature_PAC, 1
        .aeabi_attribute Tag_Feature_GCS, 1
instead of the earlier
        .section        .note.gnu.property,"a"
        .align  3
        .word   4
        .word   16
        .word   5
        .string "GNU"
        .word   0xc0000000
        .word   4
        .word   0x7
        .align  3
The former goes into .ARM.attributes section rather than .note.gnu.property as
before.
Now, when linking anything with -g -flto -mbranch-protection=standard, such as
int main () {}
gcc -flto=auto -g -mbranch-protection=standard test.c -o test
when configured against older binutils (even when actually using newer binutils
during compilation/linking) one gets
readelf -j .note.gnu.property test

Displaying notes found in: .note.gnu.property
  Owner                Data size        Description
  GNU                  0x00000010       NT_GNU_PROPERTY_TYPE_0
      Properties: AArch64 feature: BTI, PAC, GCS
but when configured against newer binutils
readelf -j .note.gnu.property test
readelf: Warning: Section '.note.gnu.property' was not dumped because it does
not exist
When linking without -flto*, both behave the same.

I think we need to copy over .ARM.attributes section, dunno if we should do it
unconditionally on all arches or somehow limit it to arm/aarch64.
But the function at least right now is not told which arch it is.  Hopefully
people
don't use .ARM.attributes sections for random stuff on other arches...