Bug 2439677
| Summary: | GCC 16.0.1-0.7.fc45 "-flto=auto -g -mbranch-protection=standard" stopped generating .note.gnu.property on AArch64 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Petr Pisar <ppisar> |
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 45 | CC: | cllang, dmalcolm, fweimer, jakub, jeremy.linton, jlaw, josmyers, jwakely, mcermak, mpolacek, msebor, nickc, nixuser, pbrobinson, pemensik, sam, sipoyare |
| Target Milestone: | --- | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | aarch64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | gcc-16.0.1-0.9.fc44 | Doc Type: | --- |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2026-03-08 00:14:51 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2439438 | ||
|
Description
Petr Pisar
2026-02-13 12:53:45 UTC
> Building zpaqfranz-64.5-1 on Fedora 44 <https://bodhi.fedoraproject.org/updates/FEDORA-2026-a32d4615b5> and on Fedora 45 <https://bodhi.fedoraproject.org/updates/FEDORA-2026-caf0f1ac36> manifests a regression in annocheck sanity test <https://artifacts.dev.testing-farm.io/2c8d7832-97dd-4cd8-83bd-4380916344a7/>, causing a Fedora CI failure with this output
I meant that on Fedora 44 there is no problem. The problem is on Fedora 45.
This also affects dovecot-fts-xapian. Note that the .o files are putting the pac/bti/gcs information in the eabi defined section use 'readelf -x | grep -i tag' to find them. The final linked exe should have them in the gnu notes sections as expected. Try `gcc main.o` just to finalize the link against the standard library and then dump the notes section. Try to use the latest built binutils as well which should understand this behavior. With old binutils-2.46-1.fc45.aarch64 the tags are present in the object file, but lost when linking:
# gcc -flto=auto -g -mbranch-protection=standard test.c -c
# readelf -a test.o | grep Tag
Tag_Feature_BTI: 1 (0x1)
Tag_Feature_PAC: 1 (0x1)
Tag_Feature_GCS: 1 (0x1)
# gcc test.o
# readelf -j .note.gnu.property a.out
readelf: Warning: Section '.note.gnu.property' was not dumped because it does not exist
After upgrading binutils to 2.46.50-1.fc45.aarch64 there is not change. Relinking the objects, or even recompiling them does not help.
(In reply to Petr Pisar from comment #5) > With old binutils-2.46-1.fc45.aarch64 the tags are present in the object > file, but lost when linking: > > # gcc -flto=auto -g -mbranch-protection=standard test.c -c > # readelf -a test.o | grep Tag > Tag_Feature_BTI: 1 (0x1) > Tag_Feature_PAC: 1 (0x1) > Tag_Feature_GCS: 1 (0x1) > # gcc test.o > # readelf -j .note.gnu.property a.out > readelf: Warning: Section '.note.gnu.property' was not dumped because it > does not exist > > > After upgrading binutils to 2.46.50-1.fc45.aarch64 there is not change. > Relinking the objects, or even recompiling them does not help. Odd, that works on my machine, gcc-16.0.1-0.7.fc45.aarch64, binutils-2.46-1.fc45.aarch64. Ok, right its that commit I was going on about that drops the out of tree patch : https://src.fedoraproject.org/rpms/binutils/c/60fb2164e569f563d14867ef04a126b8de0835b3?branch=rawhide Well, I don't see it with the koji build, nor a few builds I did with mainline, so back to annobin, is that 16.0.1-0.7.fc45? Maybe there is something else in the environment I switched to a clean VM yesterday to see what that did and the behavior remains consistent in rawhide. All of them are the latest builds available from f45-build Koji tag. Jeremy, you can set "baseurl=http://kojipkgs.fedoraproject.org/repos/f45-build/latest/$basearch" in a repository definition on your system to get the exact packages. You can also look at root.log files in Koji build tasks quoted here. There are listed versions of all packages used when the the manifesting packages were built. Big, circle but yes, if you force -g and -lto=auto and -zforce-bti then it tells you that the main.o.debug.temp.o file is missing the marking, because it is, implying that something in lto1/etc is failing to copy the eabi markings to the temp file. The f44 and f45 gcc version of gcc is the same, so unless it is because of different configure detected assembler/linker features, they should behave the same. (In reply to Jakub Jelinek from comment #11) > The f44 and f45 gcc version of gcc is the same, Since yesterday. This bug report is much older. I have hit the same problem now on strongswan PR https://src.fedoraproject.org/rpms/strongswan/pull-request/34. Clearly I am not the only one. Especially suspicious it is affects only single platform on multiple upstreams. I took Fedora 43. Upgraded it to 44. The bug is not present there because the GCC 16.0.1-0.8.fc44 is not yet in the repositories. I download and upgraded cpp, gcc, libatomic, libgcc, libgccjit, libgomp to 16.0.1-0.8.fc44 and the bug appears. Now F44 will be broken the same way as F45 once that new build gets into build root. Petr Menšík, you are not the only one. All full-arch packages built with GCC are affected. That nobody storms on devel list is because almost nobody gates Fedora builds on rpminspect results. gcc-16.0.1-0.5.fc44 had on aarch64 in its build.log: checking assembler for support of AEABI build attributes... no while gcc-16.0.1-0.8.fc44 has checking assembler for support of AEABI build attributes... yes The support for that has been in since 2024, but gas with that support supposedly appeared in F44 only in between these. So guess libiberty/simple-object.c needs to be adjusted to also copy .ARM.attributes section. FEDORA-2026-2e8e142d06 (gcc-16.0.1-0.9.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-2e8e142d06 FEDORA-2026-2e8e142d06 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-2e8e142d06` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-2e8e142d06 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2026-2e8e142d06 (gcc-16.0.1-0.9.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report. |