[Bug ld/12562] Ld.dk fails with "could not read symbols: Bad value" message
https://sourceware.org/bugzilla/show_bug.cgi?id=12562 Dmitry Gorbachev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #12 from Dmitry Gorbachev --- Old. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20828] [MIPS] produces invalid dynamic symbol table when --gc-sections is used since PR ld/13177 fix
https://sourceware.org/bugzilla/show_bug.cgi?id=20828 --- Comment #8 from Maciej W. Rozycki --- By the MIPS psABI's definition you shall not have external GGA_NONE symbols as any GGA_NONE symbols will be assigned to the local GOT part, whose entries are only relocated by the base address at the load time. Symbols in the GGA_NONE class will normally not have dynsym entries, except from selected section symbols. Any external symbols belong to the GGA_NORMAL and GGA_RELOC_ONLY classes -- depending on whether there are any GOT relocations implying signed 16-bit GP-relative access referring to them or not -- and they will be assigned to the global GOT part. The indices of those symbols will be mapped between the GOT and the dynsym table, as mandated by the MIPS psABI, according to the DT_MIPS_LOCAL_GOTNO and DT_MIPS_GOTSYM dynamic tags, such that individual entry's indices relative to the beginning of the global part of both tables will be the same. NB GGA stands for Global GOT Area. I agree the presence of (non-section) local symbols in the dynsym table is a generic issue, and given that `elf_gc_sweep_symbol' appears to be the only place where they are created I think that rather than adjusting this piece of code to assign these symbols to the GGA_NONE class it will make sense to discard them altogether. Unless there is an actual need for them, that is, which I yet need to be told about. FAOD it is not incorrect to have them -- it is just useless. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20828] [MIPS] produces invalid dynamic symbol table when --gc-sections is used since PR ld/13177 fix
https://sourceware.org/bugzilla/show_bug.cgi?id=20828 --- Comment #7 from James Cowgill --- (In reply to Maciej W. Rozycki from comment #6) > Do we need to have these hidden symbols in the dynsym table at all in > the first place? It looks like unnecessary clutter to me, they won't > ever be used for anything as their references have been gc-ed. Or am > I missing anything -- can someone confirm my conclusion or contradict > it by providing a use case? Possibly not, although it looks like a generic issue - these symbols appear when the test is run on x86_64. > If we do need these symbols in the dynsym table, then I think we just > need to set GGA_NONE for them correctly as they're being hidden and the > existing dynsym index selection code will DTRT. I don't think doing this will ensure they always appear before the other GGA_NONE global symbols. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20193] Invalid executable after adding debuglink to an executable produced after merging PE resource sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20193 --- Comment #14 from Jon Turney --- Created attachment 9666 --> https://sourceware.org/bugzilla/attachment.cgi?id=9666&action=edit Don't adjust size of PE/COFF merged .rsrc section Here's the alternate approach, of not allowing the .rsrc section to shrink. This seems to work ok (all the output .exe in my test case are valid), but this can waste a page in the output file (with the default manifest, potentially more if non-trivial resource sections were merged) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20193] Invalid executable after adding debuglink to an executable produced after merging PE resource sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20193 --- Comment #13 from Jon Turney --- (In reply to Nick Clifton from comment #12) > > > > So, another fix is needed here. I'm trying to puzzle out where to move > > rsrc_process_section() to, but if you have any pointers, that would be most > > helpful. > > Hmm, tricky. The start of coffcode.h:coff_write_object_contents() would be > my > first choice, but I have no idea what sort pf problems you might encounter... _bfd_coff_final_link() seems to be the right place. I tried adding a hook which runs at the start of that before compute_section_file_positions() is called, but that's no good, I think because the contents of the output sections aren't actually determined at that point, so this seems a bit intractable without changing lots of stuff. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20737] [aarch64] -static -pie linked binary has R_AARCH64_ABS64 relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=20737 Jiong Wang changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jiong Wang --- closed. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20737] [aarch64] -static -pie linked binary has R_AARCH64_ABS64 relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=20737 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Jiong Wang : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1dcb9720d62cd053a72c31881b7724ce9f74332c commit 1dcb9720d62cd053a72c31881b7724ce9f74332c Author: Jiong Wang Date: Thu Nov 24 14:01:53 2016 + [ARM] Bind defined symbol locally in PIE bfd/ PR target/20737 * elf32-arm.c (elf32_arm_final_link_relocate): Bind defined symbol locally in PIE. ld/ * testsuite/ld-arm/pie-bind-locally-a.s: New test source. * testsuite/ld-arm/pie-bind-locally-b.s: Likewise. * testsuite/ld-arm/pie-bind-locally.d: New testcase. * testsuite/ld-arm/arm-elf.exp: Run new testcase. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20828] [MIPS] produces invalid dynamic symbol table when --gc-sections is used since PR ld/13177 fix
https://sourceware.org/bugzilla/show_bug.cgi?id=20828 --- Comment #6 from Maciej W. Rozycki --- Do we need to have these hidden symbols in the dynsym table at all in the first place? It looks like unnecessary clutter to me, they won't ever be used for anything as their references have been gc-ed. Or am I missing anything -- can someone confirm my conclusion or contradict it by providing a use case? If we do need these symbols in the dynsym table, then I think we just need to set GGA_NONE for them correctly as they're being hidden and the existing dynsym index selection code will DTRT. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20858] [2.28 Regression] binutils fails to link with -rpath \$ORIGIN
https://sourceware.org/bugzilla/show_bug.cgi?id=20858 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- Patch applied. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20858] [2.28 Regression] binutils fails to link with -rpath \$ORIGIN
https://sourceware.org/bugzilla/show_bug.cgi?id=20858 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=51750acd087cc20ae3f72393fa897d9e3059c65d commit 51750acd087cc20ae3f72393fa897d9e3059c65d Author: Nick Clifton Date: Thu Nov 24 10:00:20 2016 + Fix snafu parsing $ORIGIN. PR ld/20858 * emultempl/elf32.em (_search_needed): Allow for path separator and terminating NUL byte when allocating space for new $ORIGIN path. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20828] [MIPS] produces invalid dynamic symbol table when --gc-sections is used since PR ld/13177 fix
https://sourceware.org/bugzilla/show_bug.cgi?id=20828 --- Comment #5 from Emilio Pozuelo Monfort --- (In reply to Alan Modra from comment #4) > On second thoughts, don't look at elf_link_output_extsym. bind_local there > can't be right since it's too late to make any decision different to that > done by _bfd_elf_link_renumber_dynsyms. So does the patch look sane? Or do you still have any comments? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 ma.jiang at zte dot com.cn changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #22 from ma.jiang at zte dot com.cn --- (In reply to Nick Clifton from comment #20) > Hi Ma, > > Well this has turned out to be a humongous patch. The problem is that > some targets break the ELF rules, so I needed to add special cases for them. > Plus the linker was not detecting all the cases where invalid program > headers were being created. Plus there were lots of test cases in the > linker testsuite that needed fixing. *sigh* Still I have finally finished > the patch and applied it. Please try out the latest development sources and > let me know if you are happy. (You could also close this PR if you are > happy...) > > Cheers > Nick Hi Nick, Thanks. I have checked the committed patch(havn't try the code though), and believe that my problem has get fixed. But I am not very happy ,as you guys have done all the work leaving me no change to "contribute to the community" :) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
