Re: rex.W prefix in jumps on x86_64

[Marc Nieper-Wißkirchen]

PING

Am Mo., 15. Juni 2020 um 17:03 Uhr schrieb Marc Nieper-Wißkirchen
<marc.nieper+gnu@gmail.com>:
>
> PS:
>
> The following patch corrects at least my issue. (The _callr function
> already did the correct thing.) All tests pass (on an Intel Core
> i7-9700).
>
> diff --git a/lib/jit_x86-cpu.c b/lib/jit_x86-cpu.c
> index 8150fa1..1db522a 100644
> --- a/lib/jit_x86-cpu.c
> +++ b/lib/jit_x86-cpu.c
> @@ -3457,7 +3457,7 @@ _calli_p(jit_state_t *_jit, jit_word_t i0)
>  static void
>  _jmpr(jit_state_t *_jit, jit_int32_t r0)
>  {
> -    rex(0, WIDE, _NOREG, _NOREG, r0);
> +    rex(0, 0, _NOREG, _NOREG, r0);
>      ic(0xff);
>      mrm(0x03, 0x04, r7(r0));
>  }
>
>
> Am Mo., 15. Juni 2020 um 16:44 Uhr schrieb Marc Nieper-Wißkirchen
> <marc.nieper+gnu@gmail.com>:
> >
> > Hi Paul,
> >
> > > >>  look at the disassembly, I see things like
> > > >>
> > > >>  rex.W jmpq *%rax
> > > >>
> > > >>  when an instruction like `jmpr R0' is jitted. I am wondering about
> > > >> the
> > > >>  REX prefix, which doesn't seem to be necessary. In 64 bit-mode,
> > > >> where
> > > >>  the operand size is fixed for jumps and calls.
> > > >>
> > >
> > > Was that introduced by commit 8dc376f?. This one introduced a bug but I
> > > can't exactly put my finger on what's going on.
> >
> > I am using the git head version, so that commit is included in my test
> > code. But that commit has something to do with jmpi's, not jmpr's.
> >
> > Which (other) bug has been introduced by that commit?
> >
> > Marc