From: Richard Henderson <richard.henderson@linaro.org>
To: Jan Bobek <jan.bobek@gmail.com>, qemu-devel@nongnu.org
Cc: "Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [Qemu-devel] [RISU RFC PATCH v1 4/7] risugen_x86: add module
Date: Thu, 27 Jun 2019 12:29:12 +0200 [thread overview]
Message-ID: <f00e9c29-592e-06b2-04cd-b3c3c28b4cc0@linaro.org> (raw)
In-Reply-To: <20190619050447.22201-5-jan.bobek@gmail.com>
On 6/19/19 7:04 AM, Jan Bobek wrote:
> + --x86_64 : generate 64-bit (rather than 32-bit) x86 code.
Better is to use
.mode x86.64
vs
.mode x86.32
or some such, like we do for aarch64.
> +sub write_mov_reg_imm($$)
> +{
> + my ($reg, $imm) = @_;
> +
> + my %insn = (opcode => {value => 0xB8 | ($reg & 0x7), len => 1},
> + imm => {value => $imm, len => $is_x86_64 ? 8 : 4});
> +
> + $insn{rex}{w} = 1 if $is_x86_64;
> + $insn{rex}{b} = 1 if $reg >= 8;
> +
> + write_insn(%insn);
> +}
There are 3 different insns that x86_64 can use for different ranges of
immediates; you are always using the full 10 byte version.
Using 0xb8 without REX.W may be used for any unsigned 32-bit value.
Using 0xc7 with REX.W may be used for any signed 32-bit value.
Using 0xb8 with REX.W of course allows any 64-bit value.
It's not terribly important, but the code size does get large.
> +sub rand_insn_modrm($$)
> +{
> + my ($opts, $insn) = @_;
> + my $modrm;
> +
> + while (1) {
> + $modrm = rand_fill({mod => {bitlen => 2},
> + reg => {bitlen => 3},
> + rm => {bitlen => 3}},
> + $opts);
> +
> + if ($modrm->{mod} != MOD_DIRECT) {
> + # Displacement only; we cannot use this since we
> + # don't know absolute address of the memblock.
> + next if $modrm->{mod} == MOD_INDIRECT && $modrm->{rm} == REG_EBP;
...
> +sub rand_insn_rex($$)
> +{
> + my ($opts, $insn) = @_;
> +
> + $opts->{w} = 0 unless defined $opts->{w};
> + $opts->{x} = 0 unless defined $opts->{x} || defined $insn->{sib};
> +
> + my $rex = rand_fill({w => {bitlen => 1},
> + r => {bitlen => 1},
> + b => {bitlen => 1},
> + x => {bitlen => 1}},
> + $opts);
I don't think it's a good idea to generate reg/rm/sib.index separate from
rex.r/b/x. In particular, all of your tests vs EBP and ESP are not quite
right, since the final insn may be referencing R12 or R13.
What is your plan for handling the unary insns for which modrm.r is opcode and
not a register? This doesn't seem to allow for those. How about insns for
which modrm.mod must be 3 (register) or must be != 3 (memory/address)? Is this
simply going to fall into "testing of illegal encodings"?
r~
next prev parent reply other threads:[~2019-06-27 10:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-19 5:04 [Qemu-devel] [RISU RFC PATCH v1 0/7] Support for generating x86 SSE/SSE2 test images Jan Bobek
2019-06-19 5:04 ` [Qemu-devel] [RISU RFC PATCH v1 1/7] risugen_common: add insnv, randint_constr, rand_fill Jan Bobek
2019-06-27 8:53 ` Richard Henderson
2019-06-28 15:10 ` Jan Bobek
2019-06-19 5:04 ` [Qemu-devel] [RISU RFC PATCH v1 2/7] risugen_x86_asm: add module Jan Bobek
2019-06-27 9:05 ` Richard Henderson
2019-06-28 15:57 ` Jan Bobek
2019-06-19 5:04 ` [Qemu-devel] [RISU RFC PATCH v1 3/7] risugen_x86_emit: " Jan Bobek
2019-06-19 5:04 ` [Qemu-devel] [RISU RFC PATCH v1 4/7] risugen_x86: " Jan Bobek
2019-06-27 10:29 ` Richard Henderson [this message]
2019-06-27 10:53 ` Richard Henderson
2019-06-28 16:03 ` Jan Bobek
2019-06-28 17:06 ` Jan Bobek
2019-06-29 12:03 ` Richard Henderson
2019-06-19 5:04 ` [Qemu-devel] [RISU RFC PATCH v1 5/7] risugen: allow all byte-aligned instructions Jan Bobek
2019-06-27 10:30 ` Richard Henderson
2019-06-19 5:04 ` [Qemu-devel] [RISU RFC PATCH v1 6/7] x86.risu: add SSE instructions Jan Bobek
2019-06-19 5:04 ` [Qemu-devel] [RISU RFC PATCH v1 7/7] x86.risu: add SSE2 instructions Jan Bobek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f00e9c29-592e-06b2-04cd-b3c3c28b4cc0@linaro.org \
--to=richard.henderson@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=jan.bobek@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).