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...
