[Bug ld/25585] [2.34 Regression] error: PHDR segment not covered by LOAD segment
https://sourceware.org/bugzilla/show_bug.cgi?id=25585 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The binutils-2_34-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=acc4a8b8ac83077819948126bc7501d35eb1ea74 commit acc4a8b8ac83077819948126bc7501d35eb1ea74 Author: Alan Modra Date: Sat Feb 22 12:46:33 2020 +1030 PR25585, PHDR segment not covered by LOAD segment I closed this bug as invalid, but I think it is worth mentioning in NEWS that older linkers didn't check PT_PHDR very well. The patch also allows people to force an output file with --noinhibit-exec after the error. bfd/ PR 25585 * elf.c (assign_file_positions_for_load_sections): Continue linking on "PHDR segment not covered by LOAD segment" errors. ld/ PR 25585 * NEWS: Mention better "PHDR segment not covered by LOAD segment" checking. (cherry picked from commit 7b3c27152b5695177a2cd5adc0d7b0255f99aca0) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25585] [2.34 Regression] error: PHDR segment not covered by LOAD segment
https://sourceware.org/bugzilla/show_bug.cgi?id=25585 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7b3c27152b5695177a2cd5adc0d7b0255f99aca0 commit 7b3c27152b5695177a2cd5adc0d7b0255f99aca0 Author: Alan Modra Date: Sat Feb 22 12:46:33 2020 +1030 PR25585, PHDR segment not covered by LOAD segment I closed this bug as invalid, but I think it is worth mentioning in NEWS that older linkers didn't check PT_PHDR very well. The patch also allows people to force an output file with --noinhibit-exec after the error. bfd/ PR 25585 * elf.c (assign_file_positions_for_load_sections): Continue linking on "PHDR segment not covered by LOAD segment" errors. ld/ PR 25585 * NEWS: Mention better "PHDR segment not covered by LOAD segment" checking. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/4499] assign file positions assumes segment offsets increasing
https://sourceware.org/bugzilla/show_bug.cgi?id=4499 Bug 4499 depends on bug 25585, which changed state. Bug 25585 Summary: [2.34 Regression] error: PHDR segment not covered by LOAD segment https://sourceware.org/bugzilla/show_bug.cgi?id=25585 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25585] [2.34 Regression] error: PHDR segment not covered by LOAD segment
https://sourceware.org/bugzilla/show_bug.cgi?id=25585 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Alan Modra --- This isn't a binutils bug, unless you believe that "PHDR segment not covered by LOAD segment" should not cause a link error. I think the ELF standard is quite clear: "PT_PHDR ... may occur only if the program header table is part of the memory image of the program" binutils-2.30, 2.31, 2.32 and 2.33 all generate a PHDR that isn't loaded by any LOAD segment, but the code checking for that problem was ineffective. This needs fixing in the linker script used by the project, or since it seems like the binary being generated is never meant to run directly on a glibc system, by linking with --no-dynamic-linker. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/23947] objcopy refuses to copy !(SEC_LOAD|SEC_ALLOC) sections
https://sourceware.org/bugzilla/show_bug.cgi?id=23947 Paul Pluzhnikov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Paul Pluzhnikov --- (In reply to Nick Clifton from comment #3) > I would like to set this PR to > RESOLVED/NOTABUG if you are happy with my answers. I am not sure I agree with "NOTABUG" resolution, but since nobody is planning to do anything about it, sure, let's close it. I tend to think of objcopy as a general tool for "copy and translate object files" (as it says on the can), and the current behavior of "you can extract/copy many, but not all sections" seems exceedingly confusing and self-inconsistent. Thanks for the --set-section-flags workaround. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25584] ar and ranlib should not call lto-wrapper for LTO bytecode
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 --- Comment #4 from Martin Liška --- Yes, I used the updated binutils to build a LTO project. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25585] New: [2.34 Regression] error: PHDR segment not covered by LOAD segment
https://sourceware.org/bugzilla/show_bug.cgi?id=25585 Bug ID: 25585 Summary: [2.34 Regression] error: PHDR segment not covered by LOAD segment Product: binutils Version: 2.35 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com CC: amodra at gmail dot com Blocks: 4499 Target Milestone: --- When building ACRN hypervisor: https://github.com/projectacrn/acrn-hypervisor on Fedora 31/x86-64 with $ dnf install python3-pip $ pip3 install kconfiglib $ make all BOARD=nuc7i7dnb SCENARIO=industry RELEASE=0 I got cc -Wl,-Map=/export/gnu/import/git/github/acrn-hypervisor/build/hypervisor/acrn.map -o /export/gnu/import/git/github/acrn-hypervisor/build/hypervisor/acrn.out -Wl,--gc-sections -nostartfiles -nostdlib -Wl,-n,-z,max-page-size=0x1000 -pie -z noreloc-overflow -T/export/gnu/import/git/github/acrn-hypervisor/build/hypervisor/link_ram.ld \ -Wl,--start-group /export/gnu/import/git/github/acrn-hypervisor/build/hypervisor/modules/lib_mod.a /export/gnu/import/git/github/acrn-hypervisor/build/hypervisor/modules/boot_mod.a /export/gnu/import/git/github/acrn-hypervisor/build/hypervisor/modules/hw_mod.a /export/gnu/import/git/github/acrn-hypervisor/build/hypervisor/modules/vp_base_mod.a /export/gnu/import/git/github/acrn-hypervisor/build/hypervisor/modules/vp_dm_mod.a /export/gnu/import/git/github/acrn-hypervisor/build/hypervisor/modules/vp_trusty_mod.a /export/gnu/import/git/github/acrn-hypervisor/build/hypervisor/modules/vp_hcall_mod.a /export/gnu/import/git/github/acrn-hypervisor/build/hypervisor/modules/libdebug.a /export/gnu/import/git/github/acrn-hypervisor/build/hypervisor/modules/sys_init_mod.a -Wl,--end-group /usr/local/bin/ld: /export/gnu/import/git/github/acrn-hypervisor/build/hypervisor/acrn.out: error: PHDR segment not covered by LOAD segment collect2: error: ld returned 1 exit status This is caused by commit 30fe183248b2523ecff9da36853e2f893c4c4b91 Author: Alan Modra Date: Wed Oct 23 17:40:51 2019 +1030 PR4499, assign file positions assumes segment offsets increasing This rewrites much of assign_file_positions_for_non_load_sections to allow objcopy and strip to handle cases like that in PR4499 where program headers were not in their usual position immediately after the ELF file header, and PT_LOAD headers were not sorted by paddr. Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=4499 [Bug 4499] assign file positions assumes segment offsets increasing -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/4499] assign file positions assumes segment offsets increasing
https://sourceware.org/bugzilla/show_bug.cgi?id=4499 H.J. Lu changed: What|Removed |Added Depends on||25585 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=25585 [Bug 25585] [2.34 Regression] error: PHDR segment not covered by LOAD segment -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25584] ar and ranlib should not call lto-wrapper for LTO bytecode
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-21 Ever confirmed|0 |1 --- Comment #3 from H.J. Lu --- (In reply to Martin Liška from comment #2) > I can confirm the patch works. Are you 100% sure? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25584] ar and ranlib should not call lto-wrapper for LTO bytecode
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 --- Comment #2 from Martin Liška --- I can confirm the patch works. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25584] ar and ranlib should not call lto-wrapper for LTO bytecode
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 --- Comment #1 from H.J. Lu --- Created attachment 12310 --> https://sourceware.org/bugzilla/attachment.cgi?id=12310&action=edit Please try this -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25584] ar and ranlib should not call lto-wrapper for LTO bytecode
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com Version|unspecified |2.35 (HEAD) Target Milestone|--- |2.35 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25584] ar and ranlib should not call lto-wrapper for LTO bytecode
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 Martin Liška changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=25355 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #65 from Martin Liška --- > > Please open a new bug. Sure: https://sourceware.org/bugzilla/show_bug.cgi?id=25584 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25584] New: ar and ranlib should not call lto-wrapper for LTO bytecode
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 Bug ID: 25584 Summary: ar and ranlib should not call lto-wrapper for LTO bytecode Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- It's a follow up of PR25355: https://sourceware.org/bugzilla/show_bug.cgi?id=25355#c63 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=25584 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #64 from H.J. Lu --- (In reply to Martin Liška from comment #63) > I have one more question about the lto-wrapper usage: is there any reason > why 'ar' and 'ranlib' also use it? It makes building of some packages > significantly slower. Please open a new bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/23947] objcopy refuses to copy !(SEC_LOAD|SEC_ALLOC) sections
https://sourceware.org/bugzilla/show_bug.cgi?id=23947 Nick Clifton changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever confirmed|1 |0 --- Comment #3 from Nick Clifton --- (In reply to Paul Pluzhnikov from comment #2) > $ objdump -sj.strtab foo.o > /build/binutils/objdump: section '.strtab' mentioned in a -j option, but not Ah - this is more of a (mis-)feature than a bug. When the BFD library reads in a file it converts some sections into special internal structure. This applies to string tables, symbol tables and relocations. This means that when objdump is asked to dump such sections it will not see them: % objdump -sj.strtab -sj.symtab -sj.rela.eh_frame foo.o objdump: section '.rela.eh_frame' mentioned in a -j option, but not found in any input file objdump: section '.symtab' mentioned in a -j option, but not found in any input file objdump: section '.strtab' mentioned in a -j option, but not found in any input file Similarly if you run "objdump --section-headers" you will not see these sections listed. In part this is why readelf might be considered to be superior to objdump, since it has no such limitations: % readelf -x.strtab -x.symtab -x.rela.eh_frame foo.o Hex dump of section '.rela.eh_frame': 0x 2000 0200 0200 ... 0x0010 Hex dump of section '.symtab': 0x 0x0010 0400f1ff Hex dump of section '.strtab': 0x 007a6f72 6b00 .zork. [I have truncated the output somewhat to save space in this reply]. Of course if you want to see the symbols in foo.o you can also use "objdump --syms foo.o" and the relocs via "objdump --reloc foo.o". There is no direct option to dump the string table however. Also, just to cover a point raised in the original bug report. The reason why the "contents are not considered meaningful in the binary format" is that in this context "binary format" actually refers to a specific file format - confusingly called 'binary' - rather than generically to any binary file. In the "binary file format" any section that is not loaded or allocated cannot have any purpose, and hence can be ignored. As for looking at the contents of a specific section, you already know about readelf's -x option (and presumably the -p and -R options), so why would you need to use objcopy to extract a section before looking at it ? Does this clear up your questions ? I would like to set this PR to RESOLVED/NOTABUG if you are happy with my answers. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #63 from Martin Liška --- I have one more question about the lto-wrapper usage: is there any reason why 'ar' and 'ranlib' also use it? It makes building of some packages significantly slower. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/23765] Malformed ELF header causes Out of Bounds read
https://sourceware.org/bugzilla/show_bug.cgi?id=23765 --- Comment #4 from Nick Clifton --- (In reply to Lokesh Janghel from comment #3) > Please let me know is it ok to go with this. Sorry - I am not a maintainer for gold. You will need to ping Ian and/or Cary . Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/23765] Malformed ELF header causes Out of Bounds read
https://sourceware.org/bugzilla/show_bug.cgi?id=23765 --- Comment #3 from Lokesh Janghel --- Hi Nick, The proposed patch from your side seems to be ok. I have verified for the error generated without segmentation fault on the latest trunk sources. Please let me know is it ok to go with this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/23765] Malformed ELF header causes Out of Bounds read
https://sourceware.org/bugzilla/show_bug.cgi?id=23765 Lokesh Janghel changed: What|Removed |Added CC||lokeshjanghel91 at gmail dot com --- Comment #2 from Lokesh Janghel --- Hi Nick, The proposed patch from your side seems to be ok. I have verified for the error generated without segmentation fault on the latest trunk sources. Please let me know is it ok to go with this. -- You are receiving this mail because: You are on the CC list for the bug.
