[Bug binutils/25543] Wrong 'readelf -p' output
https://sourceware.org/bugzilla/show_bug.cgi?id=25543 --- Comment #2 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=ba3265d04cc794d2af8b7d590a0658f7d732071c commit ba3265d04cc794d2af8b7d590a0658f7d732071c Author: Nick Clifton Date: Mon Mar 2 10:02:02 2020 + Restore readelf's string dump to previous behaviour where newlines were caused line breaks. PR 25543 * readelf.c (dump_section_as_strings): Display new-line characters as \n and then insert a line break. * testsuite/binutils-all/pr25543.s: New test. * testsuite/binutils-all/pr25543.d: Test driver. * testsuite/binutils-all/readelf.exp: Run the new test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25543] Wrong 'readelf -p' output
https://sourceware.org/bugzilla/show_bug.cgi?id=25543 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Nick Clifton --- I have checked in a modified patch, which only duisplays the offsets for the start of new strings, but which nevertheless does insert line breaks when newlines are encountered. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25543] Wrong 'readelf -p' output
https://sourceware.org/bugzilla/show_bug.cgi?id=25543 --- Comment #4 from Holger Hopp --- I think this solution is okay. Thanks -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25617] Gold looks up shared object information in section headers instead of the dynamic array
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from H.J. Lu --- Linker consumes what linker generates. Since currently linker always generates section header, linker uses it unconditionally. We need a linker switch not to generate section header. Then other consumers in binutils, like ld, nm, objdump and readelf can be updated to support it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25561] Incorrect DWARF info emitted when variable removed due to --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=25561 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |WONTFIX --- Comment #1 from Nick Clifton --- Hi Chris, > The "DW_AT_location" of a variable which is discarded as a result of using > the CFLAG -fdata-sections and the LDFLAG --gc-sections will be incorrectly > set to 0. Sadly this is a known problem and not an easy one to fix. The issue is that in order for the linker to be able to correctly discard DWARF information that is no longer relevant it must be told which pieces of information below to which variable (or function, or whatever). In order to do this the compiler needs to compartmentalise the debug information so that all the DWARF associated with one data section is placed into a separate debug section, and the two are linked together by a section group. Once this is done, the linker will automatically discard the debug information when it discards the data section. Hence this is really a gcc problem, not a binutils one. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/12269] unknown-z80-coff: Incorrect assembly of indexed register offsets from equ declarations
https://sourceware.org/bugzilla/show_bug.cgi?id=12269 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nick Clifton --- fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25572] /dev/null should be excluded from 'files are the same' check
https://sourceware.org/bugzilla/show_bug.cgi?id=25572 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Created attachment 12333 --> https://sourceware.org/bugzilla/attachment.cgi?id=12333&action=edit Proposed patch Hi Masahiro, Would a patch like this work for you ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25572] /dev/null should be excluded from 'files are the same' check
https://sourceware.org/bugzilla/show_bug.cgi?id=25572 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-03-02 Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25621] x86 jcc short/long is not relaxed to the finest.
https://sourceware.org/bugzilla/show_bug.cgi?id=25621 kaiyuan1 at andrew dot cmu.edu changed: What|Removed |Added CC||kaiyuan1 at andrew dot cmu.edu -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25621] New: x86 jcc short/long is not relaxed to the finest.
https://sourceware.org/bugzilla/show_bug.cgi?id=25621 Bug ID: 25621 Summary: x86 jcc short/long is not relaxed to the finest. Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: kaiyuan1 at andrew dot cmu.edu Target Milestone: --- Created attachment 12335 --> https://sourceware.org/bugzilla/attachment.cgi?id=12335&action=edit The source assembly and generated lst files. The example is in the attachment. The lst file was generated using: `as --32 -almns=oggenc.lst oggenc.s -o /dev/null` Here is a fragment of instructions from oggenc.lst: ### 109319 2b975 0F8E8D00 jle .LBB268_16 109319 ... 109330 2b984 8DB42600 .align 16, 0x90 109330 008D 109330 74260090 ... 109428 .LBB268_16: # %.preheader.preheader 109429 # in Loop: Header=BB268_11 Depth=2 109430 2ba08 8B4DC0movl-64(%ebp), %ecx # 4-byte Reload ### In this case, "109319 jle" used a long jcc encoding because the distance is in 0x8D offset. However, I think that this case can fit into a short jcc: If we assume that we can use a short jcc encoding, "2b975 jle" will use 2 bytes instead of 6 bytes. Then, "2b984 .align" will actually start at "2b980" because of the 4 bytes saved by a short jcc. Since "2b980" is already 16 bytes aligned, the alignment is no longer necessary, and there is another 12 bytes saved. Now, the "2b975 jle" jump distance becomes "0x8D - 0x4 - 0xC = 0x7D" offsets, which can be fit into a short jcc. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25621] x86 jcc short/long is not relaxed to the finest.
https://sourceware.org/bugzilla/show_bug.cgi?id=25621 Maverick Woo changed: What|Removed |Added CC||maverick.woo at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25622] New: [2.35 Regression] Warning: no instruction mnemonic suffix given and no register operands; using default for `cvtsi2sd'
https://sourceware.org/bugzilla/show_bug.cgi?id=25622 Bug ID: 25622 Summary: [2.35 Regression] Warning: no instruction mnemonic suffix given and no register operands; using default for `cvtsi2sd' Product: binutils Version: 2.35 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com CC: jbeulich at suse dot com Target Milestone: --- Target: i386,x86-64 Suffix warning caused many test failures on GCC 8 branch, like FAIL: gcc.dg/compat/struct-by-value-10 c_compat_y_tst.o compile with Warning: no instruction mnemonic suffix given and no register operands; using default for `cvtsi2sd' -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25622] [2.35 Regression] Warning: no instruction mnemonic suffix given and no register operands; using default for `cvtsi2sd'
https://sourceware.org/bugzilla/show_bug.cgi?id=25622 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.35 --- Comment #1 from H.J. Lu --- Many regressions in https://gcc.gnu.org/ml/gcc-regression/2020-03/msg8.html are due to this bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25622] [2.35 Regression] Warning: no instruction mnemonic suffix given and no register operands; using default for `cvtsi2sd'
https://sourceware.org/bugzilla/show_bug.cgi?id=25622 --- Comment #2 from H.J. Lu --- At least, I saw Warning: no instruction mnemonic suffix given and no register operands; using default for `cvtsi2sd' Warning: no instruction mnemonic suffix given and no register operands; using default for `cvtsi2ss' Warning: no instruction mnemonic suffix given and no register operands; using default for `vcvtsi2sd' Warning: no instruction mnemonic suffix given and no register operands; using default for `vcvtsi2ss' -- You are receiving this mail because: You are on the CC list for the bug.
