RE: extrq wrong operand?
Hi Tom Horsley, Binutils and AMD manual looks ok. PFB, the snippet from "AMD64 Architecture Programmer's Manual - Volume 3: General-Purpose and System Instructions" (Page 22 under Instruction Encoding): .. Note that the addressing mode mod = 11b is a register-direct mode, that is, the operand is contained in the specified register, while the modes mod = [00b:10b] specify different addressing modes for a memory-based operand. For mod = 11b, the register containing the operand is specified by the r/m field. For the other modes (mod = [00b:10b]), the mod and r/m fields are combined to specify the addressing mode for the memory-based operand. Most are register-indirect addressing modes meaning that the address of the memory-based operand is contained in the register specified by r/m. For these register-indirect modes, mod = 01b and mod = 10b include an offset encoded in the displacement field of the instruction. . Regards, Saravanan. -Original Message- From: bug-binutils-bounces+saravanan.ekanathan=amd@gnu.org [mailto:bug-binutils-bounces+saravanan.ekanathan=amd@gnu.org] On Behalf Of Tom Horsley Sent: Thursday, April 11, 2013 8:12 PM To: bug-binutils@gnu.org Subject: extrq wrong operand? If I'm reading the AMD manuals correctly, the extrq instruction has one form with operands described in the table as Vdq,Ib,Ib. The V in Vdq is described as being the ModRM reg field. If I disassemble an example with objdump, I see this: objdump: 40356c: 66 0f 78 c1 02 04 extrq $0x4,$0x2,%xmm1 modrm byte is 0xc1 mod = 3 reg = 0 rm = 1 So objdump seems to be picking %xmm1 from the rm field, not the reg field. Are the binutils busted, or are the AMD manuals busted? ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/15355] ppc64 linker script failure
http://sourceware.org/bugzilla/show_bug.cgi?id=15355 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|ian at airs dot com |amodra at gmail dot com -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15369] New: Wrong endian is used in cgen-dis.c.
http://sourceware.org/bugzilla/show_bug.cgi?id=15369
Bug #: 15369
Summary: Wrong endian is used in cgen-dis.c.
Product: binutils
Version: 2.24 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassig...@sourceware.org
ReportedBy: cole...@gmail.com
Classification: Unclassified
Wrong endian is used in cgen-dis.c.
When manipulating instructions,
instruction endian (`cd->insn_endian') should be used, instead of default
endian.
I think hash_insn_list() and hash_insn_array() use the wrong endian in
cgen-dis.c
for building hash table.
int big_p = CGEN_CPU_ENDIAN (cd) == CGEN_ENDIAN_BIG;
***
Instruction endian should be used intead, just like cgen_get_insn_value() and
cgen_put_insn_value()
in cgen-opc.c.
int big_p = (cd->insn_endian == CGEN_ENDIAN_BIG);
***
Otherwise, it fails to look-up an instruction in hash-table
if instruction endian differs from data endian.
value = CGEN_INSN_BASE_VALUE (insn);
bfd_put_bits ((bfd_vma) value,
buf,
CGEN_INSN_MASK_BITSIZE (insn),
big_p);
The value put in `buf' will be in reverse order.
Put in other words, the byte order in `buf' passed from cgen_get_insn_value()
and hash_insn_list/array() to `cd->dis_hash' are inconsistent.
We, on behalf of Andes Technology, are planing to contribute binutils
along with gcc and gdb around July. In our ISA, instruction endian is always
big-endian,
but data endian may be little or small. Without this fix, our disassembler
cannot work properly.
>8 >8 >8 >8 >8 >8 >8
diff --git a/opcodes/cgen-dis.c b/opcodes/cgen-dis.c
--- a/opcodes/cgen-dis.c
+++ b/opcodes/cgen-dis.c
@@ -104,7 +104,7 @@ hash_insn_array (CGEN_CPU_DESC cd,
CGEN_INSN_LIST ** htable,
CGEN_INSN_LIST * hentbuf)
{
- int big_p = CGEN_CPU_ENDIAN (cd) == CGEN_ENDIAN_BIG;
+ int big_p = (cd->insn_endian == CGEN_ENDIAN_BIG);
int i;
for (i = count - 1; i >= 0; --i, ++hentbuf)
@@ -142,7 +142,7 @@ hash_insn_list (CGEN_CPU_DESC cd,
CGEN_INSN_LIST **htable,
CGEN_INSN_LIST *hentbuf)
{
- int big_p = CGEN_CPU_ENDIAN (cd) == CGEN_ENDIAN_BIG;
+ int big_p = (cd->insn_endian == CGEN_ENDIAN_BIG);
const CGEN_INSN_LIST *ilist;
for (ilist = insns; ilist != NULL; ilist = ilist->next, ++ hentbuf)
8< 8< 8< 8< 8< 8< 8<
Any suggestion?
Wei-cheng Wang
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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
