Re: [Xen-devel] [PATCH] x86emul/test: disable pie for 64-bit builds

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.09.17 at 15:01, <wei.liu2@xxxxxxxxxx> wrote:
> On Mon, Sep 25, 2017 at 01:55:03PM +0100, Wei Liu wrote:
>> On Mon, Sep 25, 2017 at 05:54:41AM -0600, Jan Beulich wrote:
>> > >>> On 25.09.17 at 13:43, <wei.liu2@xxxxxxxxxx> wrote:
>> > > On Mon, Sep 25, 2017 at 05:35:05AM -0600, Jan Beulich wrote:
>> > >> >>> On 25.09.17 at 12:49, <wei.liu2@xxxxxxxxxx> 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.liu2@xxxxxxxxxx>
>> > >> > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> > >> > Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
>> > >> > ---
>> > >> > Cc: Jan Beulich <jbeulich@xxxxxxxx>
>> > >> > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> > >> > 
>> > >> > 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
>> > > 
>> > > My bad. The flag should be conditionally added to HOSTCFLAGS-x86_64.
>> > > 
>> > >> 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
>> > > 
>> > > It needs to be conditional because not all gcc versions support -no-pie.
>> > 
>> > You mean older one (which would be no problem, as said) or even
>> > up-to-date ones (due to the way they're being configured)?
>> 
>> Let me be precise because I don't know which version you count as old or
>> up-to-date.
>> 
>> Gcc <5.4 has -pie but no -no-pie. IIRC passing -no-pie will cause the
>> linker to return an error. I don't have a machine that old to verify it
>> though.
>> 
> 
> Actually I do have a wheezy chroot to verify that:
> 
> (wheezy)wei@zion:/local/work$ gcc --version
> gcc (Debian 4.6.3-14) 4.6.3
> 
> (wheezy)wei@zion:/local/work$ gcc -no-pie
> gcc: error: unrecognized option '-no-pie'
> gcc: fatal error: no input files
> compilation terminated.

But you said gcc would want to be passed -fno-pie anyway - does
it choke on that one too?

Jan


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