public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug gdb/18386] New: callw with 0x66 prefix incorrectly disassembled in 64-bit mode
@ 2015-05-07  3:58 m4b.github.io at gmail dot com
  0 siblings, 0 replies; only message in thread
From: m4b.github.io at gmail dot com @ 2015-05-07  3:58 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=18386

            Bug ID: 18386
           Summary: callw with 0x66 prefix incorrectly disassembled in
                    64-bit mode
           Product: gdb
           Version: 7.9
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: m4b.github.io at gmail dot com
  Target Milestone: ---

Created attachment 8304
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8304&action=edit
simple gdb session

# Bug

When a 0x66 prefix is present before a call instruction, in 64-bit mode gcc
incorrectly disassembles the call's immediate to a 16-bit value, instead of a
32-bit.

For example, for the instruction sequence:

  66 e8 01 00 00 00

gdb only consumes the first 4 bytes, instead of all 6.  On the cpu's I've
tested, the 0x66 prefix is ignored by the cpu, and all 4 bytes for the
immediate are consumed.  This seems to align with Intel's spec for call, as it
uses the f64 superscript (though it does seem to slightly contradict its use of
the Jz operand/immediate encoding).  The relevant documentation is as follows:

> The operand size is forced to a 64-bit operand size when in 64-bit mode  
>(prefixes that change operand size are ignored for this instruction in 64-bit mode)
> A-6 Vol. 2C

**NOTE** if a rex prefix is present gdb correctly ignores the 0x66 prefix

# Steps to Reproduce

1. Create a simple c program
2. compile for 64-bit mode (the default in gcc) 
3. Somewhere after main, insert the instruction sequence 66 e8 01 00 00 00,
ideally using hexl-find-file <name of binary>
4. gdb <name of binary>
5. break main
6. run
7. disass /r
8. Note the incorrect call disassembly

I've attached a gdb session from emacs, illustrating 4-8.

# Environment

uname -a
Linux derp 3.19.3-3-ARCH #1 SMP PREEMPT Wed Apr 8 14:10:00 CEST 2015 x86_64
GNU/Linux

gcc -v
gcc version 4.9.2 20150304 (prerelease) (GCC) 

gdb config
This GDB was configured as follows:
   configure --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --with-expat
             --with-gdb-datadir=/usr/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/lib/gdb (relocatable)
             --without-libunwind-ia64
             --with-lzma
             --with-python=/usr (relocatable)
             --with-guile
             --with-separate-debug-dir=/usr/lib/debug (relocatable)
             --with-system-gdbinit=/etc/gdb/gdbinit
             --with-zlib
             --without-babeltrace

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2015-05-07  3:58 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-07  3:58 [Bug gdb/18386] New: callw with 0x66 prefix incorrectly disassembled in 64-bit mode m4b.github.io at gmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).