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:50, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

I'd like to, but I can't see how, not the least because ...

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

... I've also noticed that, but the assembler would just use whatever
line directive the compiler had put in the assembly file.

Jan


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