From: Denys Vlasenko <dvlasenk@redhat.com>
To: Jim Keniston <jkenisto@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>, Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH] uprobes: fix scratch register selection for rip-relative fixups
Date: Fri, 02 May 2014 17:04:08 +0200 [thread overview]
Message-ID: <5363B3E8.6020606@redhat.com> (raw)
In-Reply-To: <1398991682.4908.22.camel@oc7886638347.ibm.com.usor.ibm.com>
On 05/02/2014 02:48 AM, Jim Keniston wrote:
> On Thu, 2014-05-01 at 19:09 +0200, Denys Vlasenko wrote:
>> +#define VEX2_VVVV(insn) X86_VEX_V((insn)->vex_prefix.bytes[1])
>> +#define VEX3_VVVV(insn) X86_VEX_V((insn)->vex_prefix.bytes[2])
>
> I disclaim any knowledge about VEX* stuff.
...
> skipped this next part...
>
>> + /* Similar treatment for VEX3 prefix */
>> + /* TODO: add XOP/EVEX treatment when insn decoder supports them */
>> + if (insn->vex_prefix.nbytes == 3) {
>> + /*
>> + * vex2: c5 rvvvvLpp (has no b bit)
>> + * vex3/xop: c4/8f rxbmmmmm wvvvvLpp
>> + * evex: 62 rxbR00mm.wvvvv1pp.zllBVaaa
>> + * (evex will need setting of both b and x since
>> + * in non-sib encoding evex.x is 4th bit of MODRM.rm)
>> + * Setting VEX3.b (setting because it has inverted meaning):
>> + */
>> + cursor = auprobe->insn + insn_offset_vex_prefix(insn) + 1;
>> + *cursor |= 0x20;
>> }
>
> ... resumed reviewing here.
I do realize that most people reading this code won't be
aficionados of memorizing x86 insn encoding quirks.
To help them, I added the comment which spells out bit layout
of vex/evex/xop prefixes (see above). Does it help?
> VEX again. Covering my ears and humming...
>
>> + if (insn->vex_prefix.nbytes == 2) {
>> + reg2 = VEX2_VVVV(insn) ^ 0xf;
>> + }
>> + if (insn->vex_prefix.nbytes == 3) {
>> + reg2 = VEX3_VVVV(insn) ^ 0xf;
>> + }
>> + /* TODO: add XOP, EXEV vvvv reading */
>> +
In fact there is room for improvement in this part:
it's better to ignore most-significant bit of this field
(32-bit mode strikes back).
>> + reg2 = 3; /* BX */
>> + if (can_use_regs & UPROBE_FIX_RIP_DI)
>> + reg2 = 7;
>> + if (can_use_regs & UPROBE_FIX_RIP_SI)
>> + reg2 = 6;
>
> It seems more natural to code this as:
> if (can_use_regs & UPROBE_FIX_RIP_SI)
> reg2 = 6;
> else if (can_use_regs & UPROBE_FIX_RIP_DI)
> reg2 = 7;
> else
> reg2 = 3; /* BX */
> ... which is pretty much how you do it in scratch_reg().
Okay.
I can also get rid of "can_use_regs" variable altogether then!
Sending new version in a jiffy.
--
vda
next prev parent reply other threads:[~2014-05-02 15:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-01 17:09 [PATCH] uprobes: fix scratch register selection for rip-relative fixups Denys Vlasenko
2014-05-01 19:11 ` Oleg Nesterov
2014-05-02 0:48 ` Jim Keniston
2014-05-02 15:04 ` Denys Vlasenko [this message]
2014-05-05 6:00 ` Jim Keniston
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=5363B3E8.6020606@redhat.com \
--to=dvlasenk@redhat.com \
--cc=jkenisto@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=srikar@linux.vnet.ibm.com \
/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