While testing parsing of build IDs from core dumps in drgn, I found that build IDs are not being properly saved in core dumps on Fedora 41. I narrowed this down to ld not placing the .note.gnu.build-id in the first page of the file. I found that there was a patch for this problem in binutils-2.43-3: https://src.fedoraproject.org/rpms/binutils/c/e92140ca5d1465981ffefe8d204edfbcd7bd271f?branch=f41 But it was dropped in binutils-2.43.1-1 because it was believed to be fixed upstream: https://src.fedoraproject.org/rpms/binutils/c/bb4d098e2f5071e7fecc3fdc68e1681d956f4274?branch=f41 However, this doesn't seem to be the case. I don't see a fix in binutils 2.43.1 upstream, and my test case still fails with binutils 2.43.1 built from source with --enable-separate-code --enable-rosegment. https://bugzilla.redhat.com/show_bug.cgi?id=2321588 seems related, so it's unclear if this is intentional. Reproducible: Always Steps to Reproduce: Run the following script: #!/bin/sh set -e echo 'int main(void) { return 0; }' | gcc -O2 -xc - -o test_core_headers objdump -h -w ./test_core_headers | awk ' $2 == ".note.gnu.build-id" { found = 1 if (strtonum("0x" $6) < 4096) { exit 0 } else { print "error: .note.gnu.build-id section not in first page" > "/dev/stderr" exit 1 } } END { if (!found) { print "error: .note.gnu.build-id section not found" > "/dev/stderr" exit 128 } }'
(In reply to Omar Sandoval from comment #0) Hi Omar, > I found that there was a patch for this problem in binutils-2.43-3: > https://src.fedoraproject.org/rpms/binutils/c/ > e92140ca5d1465981ffefe8d204edfbcd7bd271f?branch=f41 > But it was dropped in binutils-2.43.1-1 because it was believed to be fixed > upstream: > https://src.fedoraproject.org/rpms/binutils/c/ > bb4d098e2f5071e7fecc3fdc68e1681d956f4274?branch=f41 Yes - this was a mistake. Sorry. > https://bugzilla.redhat.com/show_bug.cgi?id=2321588 seems related, so it's > unclear if this is intentional. It is directly related. The problem is that with the build-id note placement patch in place binaries can no longer have their .dynamic section altered by the patchelf program. (Well strictly speaking, patchelf is no longer able to increase the size of the .dynamic section, if it has to add a new entry). This is a bug in patchelf which has been there for years, but it is only being triggered now by the change in the layout of binaries as a result of the build-id note placement patch. (Amoungst others - there have been several changes to the linker's section placement algorithms in the last year. This also provides a workaround for patchelf users: link the binary with -Wl,-z,noseparate-code which selects the old placement algorithm). The patchelf problem is important because several packages use it in order to achieve their desired functionality. (Arguably this is the wrong way to achieve that functionality, but resolving such an issue is likely to take a long time and will not affect already existing binaries). The other problem is that although this bug has been reported to the patchelf, people there has been no real action from them to fix the issue: https://bugzilla.redhat.com/show_bug.cgi?id=2319341 https://github.com/NixOS/patchelf/issues/568 https://bugzilla.redhat.com/show_bug.cgi?id=2322939 So now I have a dilemma. I can restore the build-id placement patch, and fix GDB's ability to associate core dumps with debug info files, but break packages like python, or I can leave GDB broken. Which to do ? To be honest I would prefer to restore the build-id patch. But I would also really like patchelf to be fixed too, and I just do not have the time or experience to investigate it myself. On the other hand breaking lots of things in the python world is bound to cause a lot of irate users. I have not come up with an ideal solution for this problem. I have been stalling in the hopes that someone familiar with patchelf would take an interest, but that does not seem to be happening.
Right - I have decided to restore the build-id placement patch. Packages that use patchelf and which encounter problems because of this patch can workaround the issue by adding "-Wl,-z,noseparate-code" to their final gcc command line. Ideally patchelf will be patched one day, but I do not know when. I took a look at the code myself, but I think that fixing this problem is going to involve implementing a whole new placement algorithm, rather than patching the current one. Fixed in build: binutils-2.43.1-5.fc41 Bodhi checks currently underway.
Thanks for reinstating this! It looks like there is a patchelf PR that may fix the original crash, although I haven't tested it myself: https://github.com/NixOS/patchelf/pull/544.
This message is a reminder that Fedora Linux 41 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '41'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 41 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 41 entered end-of-life (EOL) status on 2025-12-15. Fedora Linux 41 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.