[Bug binutils/16891] libopcodes decodes x86 26 9B as 'fwait' not 'es'

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |hjl.tools at gmail dot com
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.25

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Russ Cox from comment #1)
> Here are some related cases. They may be caused by something slightly
> different, since FWAIT is so special, but it didn't seem worth filing a new
> bug.

Fixed in 2.25.

> The format is: <hex bytes>: <correct answer> vs <libopcodes output>. I am
> claiming to know the <correct answer> because libopcodes is choosing to
> treat the instruction as a single byte. If so, I believe that it should
> describe the first input byte.
> 
> 66 67 ad 66 77 88 00 00: data16 vs addr16
> 66 f0 5f 66 77 88 00 00: data16 vs lock
> f2 66 67 f0 0f 11 22 00: repnz vs data16
> f2 67 ad 66 77 88 00 00: repnz vs addr16
> f2 f0 36 66 67 0f 11 22: repnz vs lock
> f3 66 67 f0 0f 11 22 00: repz vs data16
> f3 67 ad 66 77 88 00 00: repz vs addr16
> f3 f0 5f 66 77 88 00 00: repz vs lock
> f3 f2 5f 66 77 88 00 00: repz vs repnz

Please open a new bug report for each different case and be specific.
For example, with 66 67 ad 66 77 88 00 00,  I got

   0:    66 67 ad                 lods   %ds:(%si),%ax
   3:    66                       data16
   4:    77 88                    ja     0xffffff8e

Which data16 are you referring to?

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