[Bug gas/19556] GNURX toolchain generates incorrect opcode for "mov.b #0xff, [r0]" instruction.
https://sourceware.org/bugzilla/show_bug.cgi?id=19556 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Nick Clifton --- Patch checked in. -- 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/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 poma changed: What|Removed |Added See Also||https://bugzilla.redhat.com ||/show_bug.cgi?id=1308296 -- 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/19640] New: Objdump version 2.25.1 display bug -> 00 rows
https://sourceware.org/bugzilla/show_bug.cgi?id=19640 Bug ID: 19640 Summary: Objdump version 2.25.1 display bug -> 00 rows Product: binutils Version: 2.25 Status: NEW Severity: minor Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: jdetter at wisc dot edu Target Milestone: --- Created attachment 8989 --> https://sourceware.org/bugzilla/attachment.cgi?id=8989&action=edit Output of running objdump -D ./binary I'm getting some weird output bugs with using objdump with avx-512 instructions. I will get random rows of all 00's. It's not blocking me on my work, but I'm wondering if there is a way to resolve this. I have attached the example output, the bug appears on the following lines: 703, 705, 707, 709, 711, 713, 715, 717, 915, 917, 919, 921, 1006, 1008, 1010, 1012, 1097, 1099, 1101, 1103, 1105, 1107, 1109, , 1113, 1115, 1117 1119, 1121, 1123, 1125, 1127 The binary used to produce the output can be obtained here: http://cs.wisc.edu/~detter/binary Here is my version information: [detter@galapagos-01] (47)$ objdump --version GNU objdump (GNU Binutils) 2.25.1 Copyright (C) 2014 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. The command used to produce the given sample output: objdump -D ./binary -- 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 gas/19641] New: gas.texinfo build failure: "Unmatched }" and "Unknown command `code(x))'"
https://sourceware.org/bugzilla/show_bug.cgi?id=19641
Bug ID: 19641
Summary: gas.texinfo build failure: "Unmatched }" and "Unknown
command `code(x))'"
Product: binutils
Version: 2.27 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: thopre01 at gcc dot gnu.org
CC: james.greenhalgh at arm dot com, nickc at sourceware dot org
Target Milestone: ---
Host: i686-pc-linux-gnu
Target: arm-none-eabi
Build: i686-pc-linux-gnu
Hi,
gas.texinfo fails to build when building for arm-none-eabi target with the
following error:
gas/doc/as.texinfo:6384: Unmatched }.
gas/doc/as.texinfo:6392: Unknown command `code(x))'.
gas/doc/as.texinfo:6411: Unmatched }.
I believe these are due to:
* @item @{target specific} (instead of @@@var{target specific}?)
* @code(x) (instead of @code{x})
@item @@@{target specific} (instead of @@@var{target specific}?)
introduced in commit 9fb71ee49fc37163697e4f34e16097928eb83d66.
Best regards.
--
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
[libopcodes] Decoder crash and incorrect results
Hello,
I have been testing the libopcodes library with randomized binary input in the
form of 15-byte arrays. I have been using a 64-bit machine running Redhat
Enterprise Linux 6. I have found that the library will segfault given certain
inputs to print_insn_i386. Here is the code I am using to decode:
inst[] holds the bytes from left to right, zero indexed in a buffer.
INIT_DISASSEMBLE_INFO(disInfo, outf, (fprintf_ftype)fprintf);
disInfo.buffer = (bfd_byte*)(inst);
disInfo.buffer_length = nBytes;
disInfo.arch = bfd_arch_i386;
disInfo.mach = bfd_mach_x86_64_intel_syntax;
print_insn_i386((bfd_vma)0, &disInfo);
Here are several inputs that cause segfaults:
8f eb 5c ec 72 4b 4e 3c 98 df e0 ef 1d 83 00
8f ac 65 ce 46 25 66 a4 81 97 92 ea b8 19 00
8f ae f7 ef 02 51 c2 50 bc 2d f3 fb 44 65 00
8f ce 47 ee 0e 2d 08 38 70 78 aa 73 29 4e 00
8f 2d 9e ed f2 12 7d 23 19 e3 49 50 8a 50 00
In addition, I have created a filter to avoid segfaults when using the
libopcodes decoder. Here is the C code used to filter out crashing bytes:
inst[] holds the bytes from left to right, zero indexed.
if (inst[0] == (char)0x8f&&
(0x03 & (inst[1] >> 3)) == 1 &&
(0x01 & (inst[2] >> 2)) == 1 &&
((0xf0 & inst[3]) == 0xe0 || (0xf0 & inst[3]) == 0xc0) &&
((0x0f & inst[3]) > 0x0b)) {
return 1; //libopcodes would have crashed.
}
Additionally, these sequences can be prefixed as well and will cause a crash.
(I have not yet produced a filter for this, but I may soon.)
Several of the decodings produced by libopcodes were also inaccurate according
to the x86 documentation.
For example, the rep prefixes only affects string instructions (like scas,
movs, etc.), yet these are shown in other cases, such as:
repz loopne 0x5b
Lock prefixes are also allowed even when they cause an Illegal Instruction
signal. Lock prefixes should require a memory operand, but libopcodes will
produce code like:
lock mov bh, 0x9f
If I can give you more information about the machine I am running on, or
libopcodes version, let me know. If there is a nice way to get information
about the libopcodes version, I'd be happy to pass it along. This version was
compiled from a pull from the development source tree done on February 2nd with
SHA:1b18aa1e79a0b343087d08075f117e821c33b930
All the best,
Nathan Jay
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
