Re: [PATCH] x86: Fix build following c/s 623c720f "x86: use CLFLUSHOPT when available"

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 12/02/16 10:00, Jan Beulich wrote:
>>>> On 12.02.16 at 10:51, <andrew.cooper3@citrix.com> wrote:
>> On 12/02/16 08:23, Jan Beulich wrote:
>>>>>> On 11.02.16 at 20:25, <andrew.cooper3@citrix.com> wrote:
>>>> CentOS 7 gets into trouble when compiling Xen citing:
>>>>
>>>>   flushtlb.c: Assembler messages:
>>>>   flushtlb.c:149: Error: value of 256 too large for field of 1 bytes at 1
>>>>
>>>> The line number is wrong, and the error message not helpful.  It turns out
>>>> that the intermediate generated assembly was
>>>>
>>>>   # 139 "arch/x86/flushtlb.c" 1
>>>>       661:
>>>>       rex clflush (%r15)
>>>>   662:
>>>>   .pushsection .altinstructions,"a"
>>>>
>>>> and it was having trouble combining the explicit REX prefix with the REX.B
>>>> required for the use of %r15.
>>> What gas version is this? I just checked with 2.20, which has no
>>> problem combining an explicit with a generated REX prefix.
>> bash-4.2$ as --version
>> GNU assembler version 2.23.52.0.1-30.el7_1.2 20130226
>>
>>
>>>  Or
>>> wait, no, your description of the issue is wrong: It actually is the
>>> folding of the two REX prefixes which causes the problem,
>> This is what I said.  What do you think I meant with "trouble combining
>> the" ?
> Argh - I meant to say "It actually isn't ...".
>
>>>  since
>>> that results in the replacement instruction being one byte longer
>>> than the to be replaced one.
>> But that is still the case with an explicit %ds override.  The assembler
>> still has to insert an extra byte somehow.
> No. We now always have one non-REX prefix, and both instructions
> will have the same REX/ModRM/SIB encoding.

I see now, given your wording on the patch committed.

In hindsight this should have been obvious, but GCCs error message was
particularly unhelpful at diagnosing the issue.

~Andrew