[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86: Fix build following c/s 623c720f "x86: use CLFLUSHOPT when available"
>>> 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |