[Bug binutils/20699] New: [libopcodes][x86] Decodes invalid 32-bit address for a 64-bit MPX instruction
https://sourceware.org/bugzilla/show_bug.cgi?id=20699 Bug ID: 20699 Summary: [libopcodes][x86] Decodes invalid 32-bit address for a 64-bit MPX instruction Product: binutils Version: 2.26 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: njholcomb at wi dot rr.com Target Milestone: --- Libopcodes produces invalid 32-bit address for a 64-bit MPX instruction. Output: addr32 bndstx %bnd0, -0x76a5963e(%eip) # 0x895a69cb Bytes: 67 41 0f 1b 05 c2 69 5a 89 This instruction should be shown as invalid because 64-bit MPX instructions cannot act on 32-bit addresses. -- 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/19660] [libopcodes] [x86] REP prefixes shown incorrectly
https://sourceware.org/bugzilla/show_bug.cgi?id=19660 --- Comment #4 from njholcomb at wi dot rr.com --- Coming back to this, my concern is that outputting instructions with prefixes where the prefixes cause the instruction to be undefined is misleading. If the output of the decoder is intended to match the instruction that will be executed, it should produce an error, because that's what will occur when the instruction is executed on a processor. -- 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/20667] New: [libopcodes][Aarch64] IC ivau omits register operand if it's the zero register
https://sourceware.org/bugzilla/show_bug.cgi?id=20667 Bug ID: 20667 Summary: [libopcodes][Aarch64] IC ivau omits register operand if it's the zero register Product: binutils Version: 2.26 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: njholcomb at wi dot rr.com Target Milestone: --- Decoding the bytes: 0xd50b753f Should produce: ic ivau, xzr Instead produces: ic ivau I tested by attempting to assemble the instruction "ic ivau" and received the following error from gas: Error: missing register at operand 2 -- `ic ivau' This problem does not exist for other register operands. -- 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/20666] New: [libopcodes][Aarch64] BFI instruction decoded as bad BFC instruction
https://sourceware.org/bugzilla/show_bug.cgi?id=20666 Bug ID: 20666 Summary: [libopcodes][Aarch64] BFI instruction decoded as bad BFC instruction Product: binutils Version: 2.26 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: njholcomb at wi dot rr.com Target Milestone: --- Decoding an A64 base instruction with bytes: 0x331957fa should produce a bit field insert of the zero register: bfi w26, wzr, #7, #22 The current output is a BFC instruction (which already cannot be encoded in the A64 base instruction): bfc w26, #7, #22 This instruction is incorrect because the BFC instruction only supports 4 bits of register name, meaning w26 is out of bounds as a register for this instruction. -- 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/20625] New: PowerPC - cannot assemble register names from objdump
https://sourceware.org/bugzilla/show_bug.cgi?id=20625 Bug ID: 20625 Summary: PowerPC - cannot assemble register names from objdump Product: binutils Version: 2.26 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: njholcomb at wi dot rr.com Target Milestone: --- Register names produced by objdump fail to be assembled by gas, specifically r and f registers. >From objdump: : 0: c0 73 e3 d0 lfs f3,-7216(r19) >From gas assembling this instruction: test_reg_name.s: Assembler messages: test_reg_name.s:4: Error: unsupported relocation against f3 test_reg_name.s:4: Error: unsupported relocation against r19 Removing the 'f' and 'r' in front of the registers assembles appropriately. -- 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/19722] [libopcodes] [Aarch64] Undefined SIMD instruction not marked undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=19722 --- Comment #4 from njholcomb at wi dot rr.com --- This may not be a valid output from the libopcodes disassembler, but there are a lot of tools out there, and not all of them may produce expected instructions. People can also edit binaries themselves, placing arbitrary bytes. Furthermore, this instruction executes without any signal on at least one chip, where it both loads a word into x6 and applies the post-fix after loading in the word, a completely unspecified (though maybe predictable) behavior. Identifying invalid instructions like this is essential to debugging code that behaves unexpectedly. -- 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/19661] [libopcodes] [x86] Lock prefixes are allowed even when they SIGILL
https://sourceware.org/bugzilla/show_bug.cgi?id=19661 --- Comment #2 from njholcomb at wi dot rr.com --- Created attachment 9202 --> https://sourceware.org/bugzilla/attachment.cgi?id=9202=edit File displays locking without a memory operand. objdump -d lock_no_mem.o lock_no_mem.o: file format elf64-x86-64 Disassembly of section .text: : 0: 55 push %rbp 1: 48 89 e5mov%rsp,%rbp 4: f0 b7 9flock mov $0x9f,%bh 7: 96 xchg %eax,%esi 8: 00 00 add%al,(%rax) a: 00 b8 00 00 00 00 add%bh,0x0(%rax) 10: 5d pop%rbp 11: c3 retq -- 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/19660] [libopcodes] [x86] REP prefixes shown incorrectly
https://sourceware.org/bugzilla/show_bug.cgi?id=19660 --- Comment #2 from njholcomb at wi dot rr.com --- Created attachment 9201 --> https://sourceware.org/bugzilla/attachment.cgi?id=9201=edit Shows rep prefixes on non-string instructions -- 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/19659] [libopcodes] Segmentation fault on print_insn_i386
https://sourceware.org/bugzilla/show_bug.cgi?id=19659 --- Comment #2 from njholcomb at wi dot rr.com --- Created attachment 9200 --> https://sourceware.org/bugzilla/attachment.cgi?id=9200=edit File causes Abort by objdump This file contains bytes that objdump fails to decode using "objdump -d" because it aborts during decoding. -- 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/19722] [libopcodes] [Aarch64] Undefined SIMD instruction not marked undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=19722 --- Comment #2 from njholcomb at wi dot rr.com --- Hi, I'm not assembling this instruction, I am disassembling it from raw bytes. I probably should have specified that this instruction is produced as decoder output, not as assembler output. -Nathan -- 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/19722] New: [libopcodes] [Aarch64] Undefined SIMD instruction not marked undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=19722 Bug ID: 19722 Summary: [libopcodes] [Aarch64] Undefined SIMD instruction not marked undefined Product: binutils Version: 2.26 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: njholcomb at wi dot rr.com Target Milestone: --- Pair word instruction, like ldpsw, are undefined if the address for loading is specified in a register also used as a destination register. One example from libopcodes is: ldpsw x12, x6, [x6],#-8 >From the bytes: 0x68ea18cc In this case, x6 is both a destination for the load, as well as supplying the address for the load, which should be undefined. -- 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/19721] New: [libopcodes] [Aarch64] Incorrect aliasing for ORR instruction
https://sourceware.org/bugzilla/show_bug.cgi?id=19721 Bug ID: 19721 Summary: [libopcodes] [Aarch64] Incorrect aliasing for ORR instruction Product: binutils Version: 2.26 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: njholcomb at wi dot rr.com Target Milestone: --- The libopcodes decoder for aarch64 incorrectly aliases ORR instructions with the zero register but non-zero shift values to MOV instructions without signifying the shift. Below is GDB output with register info after executing one such instruction (0xaa1167e): (gdb) x/x 0x400588 0x400588 <main+16>: 0xaa1167e (gdb) x/i $pc => 0x400588 <main+16>: mov x7, x17 (gdb) info registers ... x7 0x83322 ... x170x4109d8 ... (gdb) stepi 0x0040058c in main () (gdb) info registers ... x7 0x8213b000 ... x170x4109d8 ... The instruction correct interpretation should be the ORR instruction with a left shift of 25 bits. -- 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/19661] New: [libopcodes] [x86] Lock prefixes are allowed even when they SIGILL
https://sourceware.org/bugzilla/show_bug.cgi?id=19661 Bug ID: 19661 Summary: [libopcodes] [x86] Lock prefixes are allowed even when they SIGILL Product: binutils Version: 2.27 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: njholcomb at wi dot rr.com Target Milestone: --- 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 -- 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/19660] New: [libopcodes] [x86] REP prefixes shown incorrectly
https://sourceware.org/bugzilla/show_bug.cgi?id=19660 Bug ID: 19660 Summary: [libopcodes] [x86] REP prefixes shown incorrectly Product: binutils Version: 2.27 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: njholcomb at wi dot rr.com Target Milestone: --- The rep prefixes only affects string instructions (like scas, movs, etc.), yet these are shown in other cases, such as: repz loopne 0x5b -- 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
