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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 12/02/16 10:12, Jan Beulich wrote:
>>>> 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).

Oh right.  It is an assembler BUILD_BUG_ON().

Is there anything useful we can do to get the error message to properly
point at alternative.h: DISCARD_ENTRY()?  That would at least have helped.

As it stood, the actual reported error line was a closing brace after
the wbinvd() call.

~Andrew

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