[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