Bug 172034 - bad disassembly for 0xC7 /1 "movl $___,"
bad disassembly for 0xC7 /1 "movl $___,"
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Kratochvil
:
Depends On:
Blocks: 208476 210786
  Show dependency treegraph
 
Reported: 2005-10-29 12:38 EDT by John Reiser
Modified: 2008-08-02 19:40 EDT (History)
2 users (show)

See Also:
Fixed In Version: gdb-6.5-15.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-26 18:11:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
libopcodes CVS version patch (1.59 KB, patch)
2006-06-21 12:18 EDT, Jan Kratochvil
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 2829 None None None Never

  None (edit)
Description John Reiser 2005-10-29 12:38:15 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
On x86, the byte sequence {0xc7,0310,1,2,3,4} superficially looks like "move immediate to r/m dword" because of the opcode 0xC7.  Actually, it is an illegal instruction because 0!=(070 & mod_rm); namely, the 0310 should be 0300.  Gdb disassembly should report illegal instruction, but instead says "movl $0x4030201,%eax".

Version-Release number of selected component (if applicable):
gdb-6.3.0.0-1.21

How reproducible:
Always

Steps to Reproduce:
1. Compile and run this program under gdb:
-----foo.S
_start: .globl _start
        nop; int3
        .byte 0xc7,0310,1,2,3,4
        nop; nop
-----
$ gcc -o foo -nostartfiles -nostdlib foo.S
$ gdb foo
(gdb) run
2.
3.
  

Actual Results:  Program received signal SIGTRAP, Trace/breakpoint trap.   ## as expected for 'int3'
0x08048076 in _start ()
(gdb) x/i $pc
0x8048076 <_start+2>:   mov    $0x4030201,%eax   ## gdb says it's OK
(gdb) stepi

Program received signal SIGILL, Illegal instruction.   ## CPU rejects
0x08048076 in _start ()
0x8048076 <_start+2>:   mov    $0x4030201,%eax
(gdb)


Expected Results:  Program received signal SIGTRAP, Trace/breakpoint trap.
0x08048076 in _start ()
(gdb) x/i $pc
0x8048076 <_start+2>:   (bad)  ## modrm of 0310 is illegal for opcode 0xC7


Additional info:
Comment 1 Jan Kratochvil 2006-06-21 12:18:03 EDT
Created attachment 131292 [details]
libopcodes CVS version patch

See IA-32 Intel® Architecture Software Developer's Manual Volume 2B:
Instruction Set Reference, N-Z, page 434 (of 582),
http://download.intel.com/design/Pentium4/manuals/25366719.pdf
Opcodes 0xC6 and 0xC7 do not have ('reg' (Bits 5,4,3) != 0) defined.
Comment 2 Jan Kratochvil 2006-07-15 14:24:02 EDT
H. J. Lu committed modified patch to CVS upstream.
Comment 4 Jan Kratochvil 2006-10-01 15:24:46 EDT
To be fixed in gdb-6.5-11.fc6, thanks for your bugreport.
Comment 5 Fedora Update System 2006-10-26 13:45:32 EDT
gdb-6.5-13.fc6 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 6 Christian Iseli 2007-01-19 19:06:59 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 7 John Reiser 2007-01-19 20:17:19 EST
The bug persists in gdb-6.3.0.0-1.134.fc5.
The bug has been fixed in gdb-6.5-15.fc6.
I changed the Version in this bugzilla report to 'fc5'.
Comment 8 Jan Kratochvil 2007-01-26 18:11:48 EST
While thanks for the bugreport and also the recent verification I have to say
the FC5 backport of this bug and FC5 gdb update will not happen.
FC5 is going soon into the Fedora Legacy mode.  Please upgrade to FC6 or FC7test1.

Note You need to log in before you can comment on or make changes to this bug.