)]}'
{
  "commit": "36daa9be391888b60fef1b5a2d41f11854290929",
  "tree": "0467e5075d1b242d163957427adc5fcef83bf4ca",
  "parents": [
    "74b48014179ed612ed0ea6ee4abf3b2102ef764d"
  ],
  "author": {
    "name": "Jakub Jelinek",
    "email": "jakub@redhat.com",
    "time": "Thu Mar 05 13:11:39 2026 +0100"
  },
  "committer": {
    "name": "Alan Modra",
    "email": "amodra@gmail.com",
    "time": "Mon Mar 09 08:20:25 2026 +1030"
  },
  "message": "libiberty: Copy over .ARM.attributes section into *.debug.temp.o files [PR124365]\n\nIf gcc is configured on aarch64-linux against new binutils, such as\n2.46, it doesn\u0027t emit into assembly markings like\n        .section        .note.gnu.property,\"a\"\n        .align  3\n        .word   4\n        .word   16\n        .word   5\n        .string \"GNU\"\n        .word   0xc0000000\n        .word   4\n        .word   0x7\n        .align  3\nbut instead emits\n        .aeabi_subsection aeabi_feature_and_bits, optional, ULEB128\n        .aeabi_attribute Tag_Feature_BTI, 1\n        .aeabi_attribute Tag_Feature_PAC, 1\n        .aeabi_attribute Tag_Feature_GCS, 1\nThe former goes into .note.gnu.propery section, the latter goes into\n.ARM.attributes section.\n\nNow, when linking without LTO or with LTO but without -g, all behaves\nfor the linked binaries the same, say for test.c\nint main () {}\n$ gcc -g -mbranch-protection\u003dstandard test.c -o test; readelf -j .note.gnu.property test\n\nDisplaying notes found in: .note.gnu.property\n  Owner                Data size        Description\n  GNU                  0x00000010       NT_GNU_PROPERTY_TYPE_0\n      Properties: AArch64 feature: BTI, PAC, GCS\n$ gcc -flto -mbranch-protection\u003dstandard test.c -o test; readelf -j .note.gnu.property test\n\nDisplaying notes found in: .note.gnu.property\n  Owner                Data size        Description\n  GNU                  0x00000010       NT_GNU_PROPERTY_TYPE_0\n      Properties: AArch64 feature: BTI, PAC, GCS\n$ gcc -flto -g -mbranch-protection\u003dstandard test.c -o test; readelf -j .note.gnu.property test\nreadelf: Warning: Section \u0027.note.gnu.property\u0027 was not dumped because it does not exist\n\nThe problem is that the *.debug.temp.o object files created by lto-wrapper\ndon\u0027t have these markings.  The function copies over .note.GNU-stack section\n(so that it doesn\u0027t similarly on most arches break PT_GNU_STACK segment\nflags), and .note.gnu.property (which used to hold this stuff e.g. on\naarch64 or x86, added in PR93966).  But it doesn\u0027t copy the new\n.ARM.attributes section.\n\nThe following patch fixes it by copying that section too.  The function\nunfortunately only works on names, doesn\u0027t know if it is copying ELF or some\nother format (PE, Mach-O) or if it is copying ELF, whether it is EM_AARCH64\nor some other arch.  The following patch just copies the section always,\nI think it is very unlikely people would use .ARM.attributes section for\nsome random unrelated stuff.  If we\u0027d want to limit it to just EM_AARCH64,\nguess it would need to be done in\nlibiberty/simple-object-elf.c (simple_object_elf_copy_lto_debug_sections)\ninstead as an exception for the (*pfn) callback results (and there it could\ne.g. verify SHT_AARCH64_ATTRIBUTES type but even there dunno if it has\naccess to the Ehdr stuff).\n\nNo testcase from me, dunno if e.g. the linker can flag the lack of those\nduring linking with some option rather than using readelf after link and\nwhat kind of effective targets we\u0027d need for such a test.\n\n2026-03-05  Jakub Jelinek  \u003cjakub@redhat.com\u003e\n\n\tPR target/124365\n\t* simple-object.c (handle_lto_debug_sections): Also copy over\n\t.ARM.attributes section.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "6742d3a75f469a0e789863ca256f27a6c22f31b8",
      "old_mode": 33188,
      "old_path": "libiberty/simple-object.c",
      "new_id": "a4992a2b1811040ff5b9e3eb45b1121d7b768073",
      "new_mode": 33188,
      "new_path": "libiberty/simple-object.c"
    }
  ]
}