>>> On 25.09.17 at 12:49, <wei.l...@citrix.com> wrote: > PIE may (and commonly will) result in the binary being loaded above > the 4Gb boundary, which can't work with at least the VZEROUPPER compat > mode test. > > Reported-by: Wei Liu <wei.l...@citrix.com> > Signed-off-by: Jan Beulich <jbeul...@suse.com> > Signed-off-by: Wei Liu <wei.l...@citrix.com> > --- > Cc: Jan Beulich <jbeul...@suse.com> > Cc: Andrew Cooper <andrew.coop...@citrix.com> > > With this patch, vzeroupper passes, but one other test fails. > Testing SSE packed single 64-bit code sequence...[line 368] failed!
Feel free to mail me the binary again, albeit that one's going to be more difficult to debug without being able to see it myself. > @@ -98,7 +98,9 @@ asm: > > asm/%: asm ; > > -HOSTCFLAGS += $(CFLAGS_xeninclude) -I. > +HOSTCFLAGS-x86_64 := > +$(call cc-option-add,HOSTCFLAGS,HOSTCC,-no-pie) > +HOSTCFLAGS += $(CFLAGS_xeninclude) -I. $(HOSTCFLAGS-$(XEN_COMPILE_ARCH)) I don't understand this change to my original patch: You now conditionally add -no-pie to HOSTCFLAGS (i.e. also for 32-bit builds), and HOSTCFLAGS-x86_64 remains empty. I also don't see why the addition needs to be conditional: In order to be able to build the entire test, a reasonably new tool chain is needed anyway (much newer than what we require for building everything else). And finally - is there a difference between -no-pie and -fno-PIE / -fno-pie? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
