[Bug ld/26083] New: cris linker generate zero sized PLTRELSZ
https://sourceware.org/bugzilla/show_bug.cgi?id=26083 Bug ID: 26083 Summary: cris linker generate zero sized PLTRELSZ 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: hp at sourceware dot org Target Milestone: --- Target: cris [hjl@gnu-cfl-2 ld]$ /export/build/gnu/tools-build/binutils-gitlab-cross/build-cris-elf/ld/../gas/as-new --pic --no-underscore --em=criself -I/export/gnu/import/git/gitlab/x86-binutils/ld/testsuite/ld-cris -o tmpdir/expdyn2.o /export/gnu/import/git/gitlab/x86-binutils/ld/testsuite/ld-cris/expdyn2.s [hjl@gnu-cfl-2 ld]$ ./ld-new -L/export/gnu/import/git/gitlab/x86-binutils/ld/testsuite/ld-cris --shared -m crislinux --version-script /export/gnu/import/git/gitlab/x86-binutils/ld/testsuite/ld-cris/expalltst3 --hash-style=sysv -o tmpdir/dump tmpdir/expdyn2.o [hjl@gnu-cfl-2 ld]$ /export/build/gnu/tools-build/binutils-gitlab-cross/build-cris-elf/ld/../gas/as-new --pic --no-underscore --em=criself -o tmpdir/expdref2.o /export/gnu/import/git/gitlab/x86-binutils/ld/testsuite/ld-cris/expdref2.s [hjl@gnu-cfl-2 ld]$ ./ld-new -L/export/gnu/import/git/gitlab/x86-binutils/ld/testsuite/ld-cris --shared -m crislinux --hash-style=sysv -o tmpdir/dump tmpdir/expdref2.o tmpdir/libdso-15.so [hjl@gnu-cfl-2 ld]$ readelf -d tmpdir/dump Dynamic section at offset 0x1e8 contains 17 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [tmpdir/libdso-15.so] 0x0004 (HASH) 0x94 0x0005 (STRTAB) 0x120 0x0006 (SYMTAB) 0xc0 0x000a (STRSZ) 45 (bytes) 0x000b (SYMENT) 16 (bytes) 0x0003 (PLTGOT) 0x2298 0x0002 (PLTRELSZ) 0 (bytes) Is it really needed? 0x0014 (PLTREL) RELA 0x0017 (JMPREL) 0x194 0x0007 (RELA) 0x17c 0x0008 (RELASZ) 24 (bytes) 0x0009 (RELAENT)12 (bytes) 0x6ffe (VERNEED)0x15c 0x6fff (VERNEEDNUM) 1 0x6ff0 (VERSYM) 0x14e 0x (NULL) 0x0 [hjl@gnu-cfl-2 ld]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26082] infinite loop in windmc
https://sourceware.org/bugzilla/show_bug.cgi?id=26082 --- Comment #2 from Joel Anderson --- Created attachment 12592 --> https://sourceware.org/bugzilla/attachment.cgi?id=12592=edit proposed patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26082] New: infinite loop in windmc
https://sourceware.org/bugzilla/show_bug.cgi?id=26082 Bug ID: 26082 Summary: infinite loop in windmc Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: minor Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: joelanderson333 at gmail dot com Target Milestone: --- Created attachment 12590 --> https://sourceware.org/bugzilla/attachment.cgi?id=12590=edit message missing end of message line If a message text file ends before the end of message line (a period on a line by itself), windmc will enter an infinite loop and consuming all available memory until it is killed. This can be caused by either simply leaving out the end of message line, or if it is followed by an EOF instead of a newline. I have attached two sample files that cause the issue, one for each case. I have attached a patch with the most direct solution - checking for the end of input before attempting to read the next line. This causes windmc to exit with the error message 'missing end of message text' instead of looping. While this does not perfectly match the error message of mc.exe, which reports either an invalid character or expected keyword, this seems like a more helpful error message anyway. I'm happy to apply a different fix if there is a better way to go about it, just let me know. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26082] infinite loop in windmc
https://sourceware.org/bugzilla/show_bug.cgi?id=26082 --- Comment #1 from Joel Anderson --- Created attachment 12591 --> https://sourceware.org/bugzilla/attachment.cgi?id=12591=edit message with premature EOF -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26028] Readelf truncates symbol names - which is both undocumented, and unnecessary
https://sourceware.org/bugzilla/show_bug.cgi?id=26028 Nick Clifton changed: What|Removed |Added Last reconfirmed||2020-06-04 Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|UNCONFIRMED |ASSIGNED CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Created attachment 12588 --> https://sourceware.org/bugzilla/attachment.cgi?id=12588=edit Proposed patch Hi Nadav, I agree that the symbols should really be displayed in full. But the intent has always been that readelf's output will fit neatly into an 80 column display if the --wide option is not used. So I am proposing this patch as a compromise. With the patch applied symbol names will still be displayed in a truncated format (unless --wide is used) but now they will be suffixed with "[...]" to indicate that truncation has happened. A new command line option -T/--silent-truncation will restore the old behaviour, in case there are tools that depend upon this. The patch also fixes the display of dynamic symbols so that they should end at the 80th column. Please could you try the patch out and let me know what you think. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26048] -gsplit-dwarf leads to invalid PE file
https://sourceware.org/bugzilla/show_bug.cgi?id=26048 --- Comment #2 from trass3r --- Created attachment 12587 --> https://sourceware.org/bugzilla/attachment.cgi?id=12587=edit test files Also happens with ld 2.34 from http://winlibs.com/. Works with just -g. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26048] -gsplit-dwarf leads to invalid PE file
https://sourceware.org/bugzilla/show_bug.cgi?id=26048 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to trass3r from comment #0) Are you able to reproduce this problem with the latest version of the binutils ? Release 2.30 is quite old now. Assuming that it is reproducible, please could you upload the "test.o" and "test" binaries from your example so that we can examine them. Does the problem go away if the -gsplit-dwarf option is omitted ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26080] Incorrect "Common symbol override test"
https://sourceware.org/bugzilla/show_bug.cgi?id=26080 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from H.J. Lu --- Fixed for 2.35. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26080] Incorrect "Common symbol override test"
https://sourceware.org/bugzilla/show_bug.cgi?id=26080 --- Comment #8 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c4b126b87a6cd842e567136b07ac1adca98c660f commit c4b126b87a6cd842e567136b07ac1adca98c660f Author: H.J. Lu Date: Thu Jun 4 05:58:34 2020 -0700 ELF: Don't check relocations in non-loaded, non-alloced sections Don't do anything special with non-loaded, non-alloced sections. In particular, any relocs in such sections should not affect GOT and PLT reference counting (ie. we don't allow them to create GOT or PLT entries), there's no possibility or desire to optimize TLS relocs, and there's not much point in propagating relocs to shared libs that the dynamic linker won't relocate. Since check_relocs is no longer called on non-loaded, non-alloced sections, remove SEC_ALLOC check. Resolve relocation in debug section against symbol defined in shared library to 0. bfd/ PR ld/26080 * elf-m10300.c (mn10300_elf_relocate_section): Resolve relocation in debug section against symbol defined in shared library to 0. * elf32-i386.c (elf_i386_check_relocs): Remove SEC_ALLOC check. * elf32-lm32.c (lm32_elf_check_relocs): Likewise. * elf32-m32r.c (m32r_elf_check_relocs): Likewise. * elf32-nds32.c (nds32_elf_check_relocs): Likewise. * elf32-nios2.c (nios2_elf32_check_relocs): Likewise. * elf32-or1k.c (or1k_elf_check_relocs): Likewise. * elf32-ppc.c (ppc_elf_check_relocs): Likewise. * elf32-sh.c (sh_elf_check_relocs): Likewise. * elf32-xtensa.c (elf_xtensa_check_relocs): Likewise. * elf64-alpha.c (elf64_alpha_check_relocs): Likewise. * elf64-ppc.c (ppc64_elf_check_relocs): Likewise. * elf64-x86-64.c (elf_x86_64_check_relocs): Likewise. * elfxx-mips.c (_bfd_mips_elf_check_relocs): Likewise. * elf32-vax.c (elf_vax_check_relocs): Set non_got_ref for non-GOT reference. (elf_vax_adjust_dynamic_symbol): Generate a copy reloc only if there is non-GOT reference. * elflink.c (_bfd_elf_link_check_relocs): Skip non-loaded, non-alloced sections. ld/ PR ld/26080 * testsuite/ld-elf/comm-data.exp: Remove copy_reloc. * testsuite/ld-elf/comm-data2r.rd: Removed. * testsuite/ld-elf/comm-data2r.sd: Likewise. * testsuite/ld-elf/comm-data2r.xd: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
