On Thu, 5 Mar 2026, Jakub Jelinek wrote:
> Hi!
>
> If gcc is configured on aarch64-linux against new binutils, such as
> 2.46, it doesn't emit into assembly markings like
> .section .note.gnu.property,"a"
> .align 3
> .word 4
> .word 16
> .word 5
> .string "GNU"
> .word 0xc0000000
> .word 4
> .word 0x7
> .align 3
> but instead emits
> .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
> The former goes into .note.gnu.propery section, the latter goes into
> .ARM.attributes section.
>
> Now, when linking without LTO or with LTO but without -g, all behaves
> for the linked binaries the same, say for test.c
> int main () {}
> $ gcc -g -mbranch-protection=standard test.c -o test; 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
> $ gcc -flto -mbranch-protection=standard test.c -o test; 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
> $ gcc -flto -g -mbranch-protection=standard test.c -o test; readelf -j
> .note.gnu.property test
> readelf: Warning: Section '.note.gnu.property' was not dumped because it does
> not exist
>
> The problem is that the *.debug.temp.o object files created by lto-wrapper
> don't have these markings. The function copies over .note.GNU-stack section
> (so that it doesn't similarly on most arches break PT_GNU_STACK segment
> flags), and .note.gnu.property (which used to hold this stuff e.g. on
> aarch64 or x86, added in PR93966). But it doesn't copy the new
> .ARM.attributes section.
>
> The following patch fixes it by copying that section too. The function
> unfortunately only works on names, doesn't know if it is copying ELF or some
> other format (PE, Mach-O) or if it is copying ELF, whether it is EM_AARCH64
> or some other arch. The following patch just copies the section always,
> I think it is very unlikely people would use .ARM.attributes section for
> some random unrelated stuff. If we'd want to limit it to just EM_AARCH64,
> guess it would need to be done in
> libiberty/simple-object-elf.c (simple_object_elf_copy_lto_debug_sections)
> instead as an exception for the (*pfn) callback results (and there it could
> e.g. verify SHT_AARCH64_ATTRIBUTES type but even there dunno if it has
> access to the Ehdr stuff).
>
> No testcase from me, dunno if e.g. the linker can flag the lack of those
> during linking with some option rather than using readelf after link and
> what kind of effective targets we'd need for such a test.
>
> Bootstrapped/regtested on aarch64-linux, x86_64-linux and i686-linux,
> and tested with the above mentioned test, it displays the notes even for
> -flto -g now. Ok for trunk?
LGTM. I suppose we want this also on branches after a while.
Thanks,
Richard.
> 2026-03-05 Jakub Jelinek <[email protected]>
>
> PR target/124365
> * simple-object.c (handle_lto_debug_sections): Also copy over
> .ARM.attributes section.
>
> --- libiberty/simple-object.c.jj 2026-01-02 09:56:10.569329724 +0100
> +++ libiberty/simple-object.c 2026-03-04 19:18:25.323807448 +0100
> @@ -310,6 +310,10 @@ handle_lto_debug_sections (const char *n
> /* Copy over .BTF section under the same name if present. */
> else if (strcmp (name, ".BTF") == 0)
> return strcpy (newname, name);
> + /* Copy over .ARM.attributes section under the same name if present.
> AArch64
> + aeabi attributes are present in this section. */
> + else if (strcmp (name, ".ARM.attributes") == 0)
> + return strcpy (newname, name);
> free (newname);
> return NULL;
> }
>
> Jakub
>
>
--
Richard Biener <[email protected]>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
