[PATCH] x86: tighten condition for emitting LOCK on control register accesses
H.J. Lu
hjl.tools@gmail.com
Wed May 30 14:34:00 GMT 2018
On Wed, May 30, 2018 at 7:24 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 30.05.18 at 14:36, <hjl.tools@gmail.com> wrote:
>> On Wed, May 30, 2018 at 12:42 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> The control register is never expressed by REX.B; this bit only affects
>>> the involved GPR. Also only one of the operands can have its "control"
>>> flag set, so only check the correct operand.
>>>
>>> gas/
>>> 2018-05-30 Jan Beulich <jbeulich@suse.com>
>>>
>>> * config/tc-i386.c (build_modrm_byte): Drop REX_B from condition
>>> checking for the need of emitting LOCK. Check "control" bit just
>>> once.
>>>
>>> --- a/gas/config/tc-i386.c
>>> +++ b/gas/config/tc-i386.c
>>> @@ -6894,12 +6894,11 @@ build_modrm_byte (void)
>>> if ((i.op[source].regs->reg_flags & RegVRex) != 0)
>>> i.vrex |= REX_R;
>>> }
>>> - if (flag_code != CODE_64BIT && (i.rex & (REX_R | REX_B)))
>>> + if (flag_code != CODE_64BIT && (i.rex & REX_R))
>>> {
>>> - if (!i.types[0].bitfield.control
>>> - && !i.types[1].bitfield.control)
>>> + if (!i.types[i.tm.operand_types[0].bitfield.regmem].bitfield.control)
>>> abort ();
>>> - i.rex &= ~(REX_R | REX_B);
>>> + i.rex &= ~REX_R;
>>> add_prefix (LOCK_PREFIX_OPCODE);
>>> }
>>> }
>>>
>>
>> Does it have any impact on assembly code?
>
> No - it was simply pointless from the beginning to use the more lax
> checking.
>
Patch is OK.
Thanks.
--
H.J.
More information about the Binutils
mailing list