[Bug binutils/25444] objcopy : Floating point exception in _bfd_elf_compute_section_file_positions
https://sourceware.org/bugzilla/show_bug.cgi?id=25444 --- 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=67641dd326e026b84d0e4ce47f32f71132449e27 commit 67641dd326e026b84d0e4ce47f32f71132449e27 Author: Alan Modra Date: Thu Jan 23 11:35:51 2020 +1030 PR25444, Floating point exception in _bfd_elf_compute_section_file_positions PR 25444 * elf.c (assign_file_positions_for_load_sections): Avoid divide by zero when p_align is zero. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25438] x86 MOVZ* anomalies for unusual/wrong operand combinations
https://sourceware.org/bugzilla/show_bug.cgi?id=25438 --- Comment #6 from Jan Beulich --- (In reply to H.J. Lu from comment #5) > Also > > [hjl@gnu-cfl-1 pr25438]$ cat y.s > movzwl%ax, %rcx > [hjl@gnu-cfl-1 pr25438]$ gcc -c y.s > [hjl@gnu-cfl-1 pr25438]$ objdump -dw y.o > > y.o: file format elf64-x86-64 > > > Disassembly of section .text: > > <.text>: >0: 48 0f b7 c8 movzwq %ax,%rcx And? How is this related here? This is an appropriate encoding for the insn. When optimzing, dropping the REX prefix would seem desirable. In fact this is already on my todo list. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25445] movsxd without REX_W prefix incorrectly disassembled
https://sourceware.org/bugzilla/show_bug.cgi?id=25445 --- Comment #3 from Jan Beulich --- (In reply to H.J. Lu from comment #0) >0: 66 63 08movslq (%rax),%cx Looks correct to me. (In reply to H.J. Lu from comment #1) > Also > > 63 08 movslq (%rax),%ecx This too looks correct to me. The only anomaly I can think of because of the vendor difference would be a memory operand in Intel syntax mode, which - if tagged by an operand size - might want to be WORD PTR for the 16-bit case in Intel64 mode and DWORD PTR in the AMD64 one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25444] objcopy : Floating point exception in _bfd_elf_compute_section_file_positions
https://sourceware.org/bugzilla/show_bug.cgi?id=25444 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.35 --- Comment #3 from Alan Modra --- Fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25445] movsxd without REX_W prefix incorrectly disassembled
https://sourceware.org/bugzilla/show_bug.cgi?id=25445 --- Comment #4 from H.J. Lu --- (In reply to Jan Beulich from comment #3) > (In reply to H.J. Lu from comment #0) > >0: 66 63 08movslq (%rax),%cx > > Looks correct to me. movslq is AT&T syntax for 32 bits -> 64 bits. It isn't accepted by assembler. movsxd should be here. > > (In reply to H.J. Lu from comment #1) > > Also > > > > 63 08 movslq (%rax),%ecx > > This too looks correct to me. movsxd should be here. > The only anomaly I can think of because of the vendor difference would be a > memory operand in Intel syntax mode, which - if tagged by an operand size - > might want to be WORD PTR for the 16-bit case in Intel64 mode and DWORD PTR > in the AMD64 one. Manual can be wrong. The current Intel manual says that MOVSXD is valid for 32-bit. Can you double check MOVSXD on AMD processor to verify movsxd (%rax), %cx does load 4 bytes? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25438] x86 MOVZ* anomalies for unusual/wrong operand combinations
https://sourceware.org/bugzilla/show_bug.cgi?id=25438 --- Comment #7 from H.J. Lu --- (In reply to Jan Beulich from comment #6) > (In reply to H.J. Lu from comment #5) > > Also > > > > [hjl@gnu-cfl-1 pr25438]$ cat y.s > > movzwl %ax, %rcx > > [hjl@gnu-cfl-1 pr25438]$ gcc -c y.s > > [hjl@gnu-cfl-1 pr25438]$ objdump -dw y.o > > > > y.o: file format elf64-x86-64 > > > > > > Disassembly of section .text: > > > > <.text>: > >0: 48 0f b7 c8 movzwq %ax,%rcx > > > And? How is this related here? This is an appropriate encoding for the insn. > When optimzing, dropping the REX prefix would seem desirable. In fact this > is already on my todo list. It is OK to encode "movzwq %ax,%rcx" as "movzwl %ax,%ecx". But assembler shouldn't accept "movzwl %ax,%rcx". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25438] x86 MOVZ* anomalies for unusual/wrong operand combinations
https://sourceware.org/bugzilla/show_bug.cgi?id=25438 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-23 Ever confirmed|0 |1 --- Comment #9 from H.J. Lu --- (In reply to Jan Beulich from comment #8) > (In reply to H.J. Lu from comment #7) > > It is OK to encode "movzwq %ax,%rcx" as "movzwl %ax,%ecx". But assembler > > shouldn't accept "movzwl %ax,%rcx". > > But addressing this is part of the second patch referenced by the original > description here. Please submit a single patch to fix this bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25438] x86 MOVZ* anomalies for unusual/wrong operand combinations
https://sourceware.org/bugzilla/show_bug.cgi?id=25438 --- Comment #8 from Jan Beulich --- (In reply to H.J. Lu from comment #7) > It is OK to encode "movzwq %ax,%rcx" as "movzwl %ax,%ecx". But assembler > shouldn't accept "movzwl %ax,%rcx". But addressing this is part of the second patch referenced by the original description here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25438] x86 MOVZ* anomalies for unusual/wrong operand combinations
https://sourceware.org/bugzilla/show_bug.cgi?id=25438 --- Comment #11 from H.J. Lu --- (In reply to Jan Beulich from comment #10) > (In reply to H.J. Lu from comment #9) > > Please submit a single patch to fix this bug. > > How is > > https://sourceware.org/ml/binutils/2019-12/msg00346.html > > not a single patch? From that series > - patches 1 and 2 have been committed > - patch 3 demonstrates current (good as well as bad) behavior, to help show > more clearly how ... This bug should be opened first when you were preparing for these patches. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25438] x86 MOVZ* anomalies for unusual/wrong operand combinations
https://sourceware.org/bugzilla/show_bug.cgi?id=25438 --- Comment #10 from Jan Beulich --- (In reply to H.J. Lu from comment #9) > Please submit a single patch to fix this bug. How is https://sourceware.org/ml/binutils/2019-12/msg00346.html not a single patch? From that series - patches 1 and 2 have been committed - patch 3 demonstrates current (good as well as bad) behavior, to help show more clearly how ... - patch 4 fixes this issue (alongside other ones, but all by the same actual code changes). Would you _please_ take a _proper_ look at patches 3 and 4 of that series? It is telling enough that you moved from an initial "We can't change the encoding nor disallow it." response to "movzbw %al, %ecx movzbw %al, %rcx movzbl %al, %cx movzbl %al, %rcx movzbq %al, %cx movzbq %al, %ecx should be hard error. Clearly they are typos." -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25445] movsxd without REX_W prefix incorrectly disassembled
https://sourceware.org/bugzilla/show_bug.cgi?id=25445 --- Comment #5 from Jan Beulich --- (In reply to H.J. Lu from comment #4) > (In reply to Jan Beulich from comment #3) > > (In reply to H.J. Lu from comment #0) > > >0: 66 63 08movslq (%rax),%cx > > > > Looks correct to me. > > movslq is AT&T syntax for 32 bits -> 64 bits. It isn't accepted by > assembler. movsxd should be here. MOVSXD, like MOVSX and MOVZX, is Intel syntax, and hence has nothing to do in AT&T syntax disassembly. > > (In reply to H.J. Lu from comment #1) > > > Also > > > > > > 63 08 movslq (%rax),%ecx > > > > This too looks correct to me. > > movsxd should be here. Same here. > > The only anomaly I can think of because of the vendor difference would be a > > memory operand in Intel syntax mode, which - if tagged by an operand size - > > might want to be WORD PTR for the 16-bit case in Intel64 mode and DWORD PTR > > in the AMD64 one. > > Manual can be wrong. The current Intel manual says that MOVSXD is valid > for 32-bit. Can you double check MOVSXD on AMD processor to verify > > movsxd (%rax), %cx > > does load 4 bytes? I did already around the time I put together https://sourceware.org/ml/binutils/2019-12/msg00347.html Both manuals accurately describe actual hardware behavior. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25445] movsxd without REX_W prefix incorrectly disassembled
https://sourceware.org/bugzilla/show_bug.cgi?id=25445 --- Comment #6 from H.J. Lu --- (In reply to Jan Beulich from comment #5) > (In reply to H.J. Lu from comment #4) > > (In reply to Jan Beulich from comment #3) > > > (In reply to H.J. Lu from comment #0) > > > >0: 66 63 08movslq (%rax),%cx > > > > > > Looks correct to me. > > > > movslq is AT&T syntax for 32 bits -> 64 bits. It isn't accepted by > > assembler. movsxd should be here. > > MOVSXD, like MOVSX and MOVZX, is Intel syntax, and hence has nothing to do > in AT&T syntax disassembly. > There is no such an instruction of "movslq (%rax),%cx". -- You are receiving this mail because: You are on the CC list for the bug.
Issue 19643 in oss-fuzz: binutils:fuzz_disassemble: Undefined-shift in print_insn_d30v
Updates: Labels: -restrict-view-commit Comment #3 on issue 19643 by sheriff...@chromium.org: binutils:fuzz_disassemble: Undefined-shift in print_insn_d30v https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19643#c3 This bug has been fixed for 30 days. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 19647 in oss-fuzz: binutils:fuzz_bfd: Heap-buffer-overflow in bfd_getl16
Updates: Labels: -restrict-view-commit Comment #3 on issue 19647 by sheriff...@chromium.org: binutils:fuzz_bfd: Heap-buffer-overflow in bfd_getl16 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19647#c3 This bug has been fixed for 30 days. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 19624 in oss-fuzz: binutils:fuzz_disassemble: Undefined-shift in wasm_read_leb128
Updates: Labels: -restrict-view-commit Comment #3 on issue 19624 by sheriff...@chromium.org: binutils:fuzz_disassemble: Undefined-shift in wasm_read_leb128 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19624#c3 This bug has been fixed for 30 days. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 19650 in oss-fuzz: binutils:fuzz_bfd: Heap-buffer-overflow in add_symbol
Updates: Labels: -restrict-view-commit Comment #3 on issue 19650 by sheriff...@chromium.org: binutils:fuzz_bfd: Heap-buffer-overflow in add_symbol https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19650#c3 This bug has been fixed for 30 days. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug binutils/25445] movsxd without REX_W prefix incorrectly disassembled
https://sourceware.org/bugzilla/show_bug.cgi?id=25445 --- Comment #7 from H.J. Lu --- A patch is posted at https://sourceware.org/ml/binutils/2020-01/msg00344.html -- You are receiving this mail because: You are on the CC list for the bug.
Strange singular/plural messages in 2.33.90
While translating 2.33.90 to Swedish, I came across this code from readelf.c:
warn (ngettext ("debuginfod: Corrupt note: only %ld byte remains, "
"not enough for a full note\n",
"Corrupt note: only %ld bytes remain, "
"not enough for a full note\n",
data_remaining),
(long) data_remaining);
It seems strange you would want the "debuginfod" prefix only in the
case of singular, while the plural form has no such prefix. I suspect
that is a mistake.
The code snippet appears twice.
Misspelling of "alpha"
Another thing I noticed while translating 2.33.90 to Swedish was this message in readelf.c where "alpha" is misspelled: Unrecognized alpah specific other value: %u
