https://sourceware.org/bugzilla/show_bug.cgi?id=20702
--- Comment #1 from nholcomb at wisc dot edu ---
This issue appears for return instructions as well. The data16 prefix should
not affect instructions acting on address-size dependent operands.
Return example:
Bytes: 66 c3
Instruction: retw
https://sourceware.org/bugzilla/show_bug.cgi?id=20706
--- Comment #4 from nholcomb at wisc dot edu ---
These input bytes were generated as a way to validate instruction decoders.
They are not a part of a real executable, so they weren't created by an
assembler.
--
You are receiving this
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
The following bytes correspond to an unallocated encoding according to the
ARMv8 referenece manual: ec f4 c2 4d.
However, libopcodes
https://sourceware.org/bugzilla/show_bug.cgi?id=21123
--- Comment #2 from nholcomb at wisc dot edu ---
Should this work with -many? It currently does not.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils
https://sourceware.org/bugzilla/show_bug.cgi?id=21124
--- Comment #2 from nholcomb at wisc dot edu ---
The instruction is invalid. The ".long 0x7c228" tells anyone looking at the
assembly that the instruction is invalid. I think the decoding should be
obviously invalid, instead of
https://sourceware.org/bugzilla/show_bug.cgi?id=21125
--- Comment #2 from nholcomb at wisc dot edu ---
(In reply to Alan Modra from comment #1)
> Pass -mpower4 or above to gas in order to enable these insns.
Should -many work?
I can assemble this instruction with two operands using -many,
: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
Both DCBT and DCBTST instructions have three operand forms as follows:
dcbt RA,RB,TH
dcbtst RA,RB,TH
However, assembling
Version: 2.26
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
The source and target registers must be different for
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
When I try to assemble the instruction "tlbie r10, r26, 1, 1, 1", gas produces
the erro
: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
The RLMI instruction was deprecated from POWER to PowerPC but is produced
during decoding of PowerPC 64.
Example
NCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
The following bytes correspond to a 2-byte sal instruction, but libpocodes
produces a 1-byte &quo
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
The following are the bytes of a test instruction and the expected output.
Libopcodes returns a "
: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
The following are examples of objdump output XOP instructions using %ymm
registers that produce invalid size errors
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
The following instruction produced by objdump cannot be assembled with gas due
to an error.
Bytes: c5 ac 46 f5
https://sourceware.org/bugzilla/show_bug.cgi?id=20704
--- Comment #1 from nholcomb at wisc dot edu ---
The following bytes produce only the opcode when decoded. The bytes themselves
do not appear to be a valid instruction.
Bytes: 0f 7a 20 72
Output: ptest
--
You are receiving this mail because
https://sourceware.org/bugzilla/show_bug.cgi?id=20704
nholcomb at wisc dot edu changed:
What|Removed |Added
Summary|[libopcodes][x86] |[libopcodes][x86] Decodes
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https
: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
The following instruction produced by objdump cannot be assembled by GAS due to
an error:
Bytes: 62 c1 95 00 f4 41 42
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
The following instruction (output of objdump) could not be assembled using GAS
due to the error:
Bytes: 66 0f
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
The following instruction (output of objdump) could not be assembled using GAS
due to the error:
Bytes: 0f 7a 47 22
Instruction
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: nholcomb at wisc dot edu
Target Milestone: ---
The xbegin instruction should only works with 16-bit or 32-bit offsets, so the
'q' suffix is invalid.
Bytes: c7 f8 80 aa 33 90
Output: xbeginq 0xff
https://sourceware.org/bugzilla/show_bug.cgi?id=19660
--- Comment #6 from nholcomb at wisc dot edu ---
The fact that the rep prefixes cannot be used with these opcodes is not the
same as machine dependencies. This instruction will be invalid everywhere, so
it should be decoded as invalid
22 matches
Mail list logo
