This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [committed, PATCH] PR binutis/18386: callw with 0x66 prefix incorrectly disassembled in 64-bit mode
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: "Binutils" <binutils at sourceware dot org>
- Date: Tue, 12 May 2015 10:42:40 +0100
- Subject: Re: [committed, PATCH] PR binutis/18386: callw with 0x66 prefix incorrectly disassembled in 64-bit mode
- Authentication-results: sourceware.org; auth=none
- References: <20150509135213 dot GA720 at gmail dot com> <555076520200007800078B8F at mail dot emea dot novell dot com> <CAMe9rOpRdCftue3uFgaejAYZbi=kC91y7sXkfWg-8py3Nmy5kw at mail dot gmail dot com> <5550AEC30200007800078E84 at mail dot emea dot novell dot com> <CAMe9rOpzDYMgbBfCbuQBhNHT=VX3u11EpCMqzWFoy5bByfxFRw at mail dot gmail dot com> <5550C9360200007800078FA7 at mail dot emea dot novell dot com> <CAMe9rOobPn=Dqqq-+=N4AExzDQ7uYP8vtA3WY07Hh7U5t_rtKQ at mail dot gmail dot com>
>>> On 11.05.15 at 15:33, <hjl.tools@gmail.com> wrote:
> So AMD and Intel are different. I think
>
> data16 callq rel32
>
> is better than
>
> callw rel16
> foobar
I don't think so - neither is going to result in proper disassembly of
following instructions when looked at from the opposite corner. I.e.
disassembling as instruction with 2-byte displacement when it was
written with a 4-byte one will yield rubbish for the two extra
bytes, while disassembling as instruction with 4-byte displacement
when it was written with a 2-byte one will wrongly consume the
next instruction's first two bytes. Without the user telling you (via
command line option or alike; in live gdb sessions it may also be
possible to simply default to the CPU being run on) and without a
relocation to infer the displacement size from, you just can't get it
right (and what was there before your patch was as good or as
bad as what is there now).
But of course a pretty clear conclusion here is - unless people
intentionally write vendor specific code, use of overrides with
these instructions would perhaps best be considered invalidating
the instructions altogether (i.e. an even more reasonable default
in the absence of knowing any better might be to disassemble
them just like other undefined ones).
Jan