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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.02.16 at 11:02, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 12/02/16 10:00, Jan Beulich wrote:
>>>>> On 12.02.16 at 10:51, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 12/02/16 08:23, Jan Beulich wrote:
>>>>>>> On 11.02.16 at 20:25, <andrew.cooper3@xxxxxxxxxx> 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.

It was actually an assembler error message, and I can't really see
how we could improve that (since afaict the intended checking can
only be done at assembly time).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel