From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86: Fix build following c/s 623c720f "x86: use CLFLUSHOPT when available" Date: Fri, 12 Feb 2016 10:02:41 +0000 Message-ID: <56BDADC1.2050204@citrix.com> References: <1455218743-12751-1-git-send-email-andrew.cooper3@citrix.com> <56BDA49A02000078000D146C@prv-mh.provo.novell.com> <56BDAB0E.3050208@citrix.com> <56BDBB3002000078000D155B@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56BDBB3002000078000D155B@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org On 12/02/16 10:00, Jan Beulich wrote: >>>> On 12.02.16 at 10:51, wrote: >> On 12/02/16 08:23, Jan Beulich wrote: >>>>>> On 11.02.16 at 20:25, 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