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:57, Jan Beulich wrote:
>>>> 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.

Hmm.

Well, the one saving grace is that if you google the error message, you
now get to this thread.  Hopefully this might help someone else out of a
similar situation in the future.

~Andrew

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