The file offset of the .note.gnu.property section in a debuginfo file does not match its VMA. For example: % readelf --wide -S /usr/lib/systemd/libsystemd-shared-239.so [Nr] Name Type Address Off Size ES Flg Lk Inf Al [...] [19] .note.gnu.property NOTE 00000000001fde88 1fde88 000020 00 A 0 0 8 Note that the offset matches the address. This matters because of how sections are mapped to segments: % readelf --wide -l /usr/lib/systemd/libsystemd-shared-239.so Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Al [...] NOTE 0x1fde88 0x00000000001fde88 0x00000000001fde88 0x000020 0x000020 R 0x8 [...] 06 .note.gnu.property By contrast, in the debuginfo file for this shared library, the offset of the .note.gnu.property section has been changed: % readelf --wide -S /usr/lib/debug/usr/lib/systemd/libsystemd-shared-239.so-239-11.git4dc7dce.fc29.x86_64.debug [...] [Nr] Name Type Address Off Size ES Flg Lk Inf Al [...] [19] .note.gnu.property NOTE 00000000001fcd18 0002e0 000020 00 A 0 0 8 So now the .note.gnu.property section is no longer mapped to segment 6: readelf --wide -l /usr/lib/debug/usr/lib/systemd/libsystemd-shared-239.so-239-11.git4dc7dce.fc29.x86_64.debug [...] Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Al NOTE 0x1fcd18 0x00000000001fcd18 0x00000000001fcd18 0x000020 0x000020 R 0x8 [...] 06 It is also worth pointing out that the same issue does not affect the .note.build-id section... This also means that when the debuginfo file is processed either by gdb or objcopy, a warning is generated: warning: allocated section `.note.gnu.property' not in segment This PR is in response to Fedora BZ 1553086: https://bugzilla.redhat.com/show_bug.cgi?id=1553086
Shouldn't this bug be in "binutils" component ? The debuginfo file is created by "objcopy --only-keep-debug", which removes sections but doesn't seem to update the offset in segment headers.
A main executable and a separate debug file have the exact same program headers. This is to make matching them together easier. It also helps to have to original program headers in the debug file for unstrip when the main executable file has been prelinked, so you can still recombine them. You cannot rely on the program headers in a .debug file since all allocated sections (except for SHT_NOTES) have been replaced by NOBITS. The reason this seems to work out for the .build_id NOTE is because it is always put at the front of the file, so no other sections are removed before it when put into a .debug file (and so the offset stays the same). If you want this to work for any other allocated NOTEs then the linker would have to sort them together at the front of the file (right after the .build-id NOTE, the .build-id NOTE should always be first, so it gets dumped with the ELF headers in a core file). But in general I would say that programs that rely on the program headers in a split .debug file are just broken.
Is this a dup of PR 23035?
(In reply to H.J. Lu from comment #3) > Is this a dup of PR 23035? No, I do not think so.
(In reply to Mark Wielaard from comment #2) > But in general I would say that programs that rely on the program headers in > a split .debug file are just broken. Agreed - but, the problem is that the BFD library is generating the warning message "allocated section `.note.gnu.property' not in segment" when asked to process .debug files on behalf of tools like gdb and objcopy. Presumably it would make sense to silence this warning when processing .debug files. Is there a reliable way to detect them ? For example can such files always be assumed to have a .text section with a SHT_NOBITS type ?
(In reply to Nick Clifton from comment #5) > Presumably it would make sense to silence this warning when processing .debug > files. Is there a reliable way to detect them ? For example can such files > always be assumed to have a .text section with a SHT_NOBITS type ? There was a proposal to give such files a unique (ET_GNU_DEBUG_REL|EXEC|DYN) type. But that was never implemented. So you would indeed need some heuristic. Such files don't have any allocated SHT_PROGBITS sections. The only allocated sections are SHT_NOBITS or SHT_NOTES.
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1faa385ff6b11df26efc46152fe15b31adbf8624 commit 1faa385ff6b11df26efc46152fe15b31adbf8624 Author: Nick Clifton <nickc@redhat.com> Date: Tue Jul 2 15:58:29 2019 +0100 Stop the BFD library from issuing a warning message when processing allocated sections in debuginfo files that lie outside of any loadable segment. PR 24717 * elf.c (is_debuginfo_file): New function. (assign_file_positions_for_non_load_sections): Do not warn about allocated sections outside of loadable segments if they are found in a debuginfo file. * elf-bfd.h (is_debuginfo_file): Prototype.
I have gone ahead and applied my patch. I still do not have a good test for it, but I think that it is important that it is in the sources before the next release happens. I will leave this PR open until I can think of a way to test the fix.
Nick you changed this one to "ASSIGNED" but left the unassigned user. Fixing.
Hi Alan, > Nick you changed this one to "ASSIGNED" but left the unassigned user. Fixing. Thanks. I thought that setting the assignee happened automatically if it was set to "unassigned". Oh well, I will remember to check in the future. Cheers Nick
Fixed as per comment #7