x86emul/test: disable pie for 64-bit builds
PATCH 1/1 x86emul/test: disable pie for 64-bit builds
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.
---
Cc: Jan Beulich <[email protected]>
Cc: Andrew Cooper <[email protected]>
With this patch, vzeroupper passes, but one other test fails. Testing SSE packed single 64-bit code sequence...[line 368] failed!
--- tools/tests/x86_emulator/Makefile | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
tools/tests/x86_emulator/Makefile +4 -2
@@ -76,7 +76,7 @@ $(addsuffix .c,$(SIMD)) $(addsuffix -avx.c,$(filter sse%,$(SIMD))): ln -sf simd.c $@ $(TARGET): x86_emulate.o test_x86_emulator.o - $(HOSTCC) -o $@ $^ + $(HOSTCC) $(HOSTCFLAGS) -o $@ $^ .PHONY: clean clean:
@@ -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)) x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h x86_emulate.h := x86_emulate.h x86_emulate/x86_emulate.h $(x86.h)
Signature · 7 lines
2.11.0 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xen.org/xen-devel
Quoted 8 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 12:49, <[email protected]> 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 <[email protected]>Signed-off-by Jan Beulich <[email protected]>Signed-off-by Wei Liu <[email protected]>
Quoted 6 lines
---
Cc: Jan Beulich <[email protected]>
Cc: Andrew Cooper <[email protected]>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.
tools/tests/x86_emulator/Makefile asm: · line 103
Quoted 8 lines
tools/tests/x86_emulator/Makefile +3
-1@@ -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
[email protected]
https://lists.xen.org/xen-devel
Quoted 22 lines · Jan Beulich
Quoted 8 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 12:49, <[email protected]> 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 <[email protected]>Signed-off-by Jan Beulich <[email protected]>Signed-off-by Wei Liu <[email protected]>Quoted 6 lines
---
Cc: Jan Beulich <[email protected]>
Cc: Andrew Cooper <[email protected]>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.
Quoted 4 lines
tools/tests/x86_emulator/Makefile +0
-0@@ -98,7 +98,9 @@ asm: asm/%: asm ;
Quoted 8 lines
tools/tests/x86_emulator/Makefile asm: · line 103
Quoted 4 lines
tools/tests/x86_emulator/Makefile +3
-1-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.
Quoted 3 lines
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.
Quoted 2 lines
- is there a difference between -no-pie and -fno-PIE / -fno-pie?
I can't tell the difference by reading the manpage TBH. I only know one works while the other doesn't by trial and error.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 33 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 13:43, <[email protected]> wrote:
Quoted 22 lines · Jan Beulich
Quoted 8 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 12:49, <[email protected]> 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 <[email protected]>Signed-off-by Jan Beulich <[email protected]>Signed-off-by Wei Liu <[email protected]>Quoted 6 lines
---
Cc: Jan Beulich <[email protected]>
Cc: Andrew Cooper <[email protected]>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.
Quoted 4 lines
tools/tests/x86_emulator/Makefile +0
-0@@ -98,7 +98,9 @@ asm: asm/%: asm ;Quoted 8 lines
tools/tests/x86_emulator/Makefile asm: · line 103
Quoted 4 lines
tools/tests/x86_emulator/Makefile +3
-1-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
Quoted 7 lines
My bad. The flag should be conditionally added to HOSTCFLAGS-x86_64.
Quoted 3 lines
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)?
Quoted 5 lines
Quoted 2 lines
- is there a difference between -no-pie and -fno-PIE / -fno-pie?
I can't tell the difference by reading the manpage TBH. I only know one works while the other doesn't by trial and error.
Oh, that's certainly worthwhile adding to the description then.
Jan
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 35 lines · Jan Beulich
Quoted 35 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 13:43, <[email protected]> wrote:
Quoted 22 lines · Jan Beulich
Quoted 8 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 12:49, <[email protected]> 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 <[email protected]>Signed-off-by Jan Beulich <[email protected]>Signed-off-by Wei Liu <[email protected]>Quoted 6 lines
---
Cc: Jan Beulich <[email protected]>
Cc: Andrew Cooper <[email protected]>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.
Quoted 4 lines
tools/tests/x86_emulator/Makefile +0
-0@@ -98,7 +98,9 @@ asm: asm/%: asm ;Quoted 8 lines
tools/tests/x86_emulator/Makefile asm: · line 103
Quoted 4 lines
tools/tests/x86_emulator/Makefile +3
-1-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.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
- is there a difference between -no-pie and -fno-PIE / -fno-pie?
I can't tell the difference by reading the manpage TBH. I only know one works while the other doesn't by trial and error.
Oh, that's certainly worthwhile adding to the description then.
After reading a bit more into the manual: the -no-pie option is for the linker, while the -fno-pie option is for code generation.
The build rune is in fact using HOSTCC to link the executable, hence we need -fno-pie.
I'm not sure why omitting -fno-PIE is not a problem, but it works.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 46 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 14:55, <[email protected]> wrote:
Quoted 35 lines · Jan Beulich
Quoted 35 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 13:43, <[email protected]> wrote:
Quoted 22 lines · Jan Beulich
Quoted 8 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 12:49, <[email protected]> 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 <[email protected]>Signed-off-by Jan Beulich <[email protected]>Signed-off-by Wei Liu <[email protected]>Quoted 6 lines
---
Cc: Jan Beulich <[email protected]>
Cc: Andrew Cooper <[email protected]>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.
Quoted 4 lines
tools/tests/x86_emulator/Makefile +0
-0@@ -98,7 +98,9 @@ asm: asm/%: asm ;Quoted 8 lines
tools/tests/x86_emulator/Makefile asm: · line 103
Quoted 4 lines
tools/tests/x86_emulator/Makefile +3
-1-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.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
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)?
Quoted 6 lines
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.
Okay, gcc below 5 counts as "old" here for me; iirc I had to update to that version to actually be able to properly build and run all current tests.
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
- is there a difference between -no-pie and -fno-PIE / -fno-pie?
I can't tell the difference by reading the manpage TBH. I only know one works while the other doesn't by trial and error.
Oh, that's certainly worthwhile adding to the description then.
Quoted 7 lines
After reading a bit more into the manual: the -no-pie option is for the linker, while the -fno-pie option is for code generation.
The build rune is in fact using HOSTCC to link the executable, hence we need -fno-pie.
I'm not sure why omitting -fno-PIE is not a problem, but it works.
All pretty confusing. Are you going to send a cleaned up patch then?
Jan
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 3 lines · Jan Beulich
Quoted 3 lines
The build rune is in fact using HOSTCC to link the executable, hence we need -fno-pie.
This should be "we need -no-pie", sorry.
Quoted 4 lines
Quoted 1 line
I'm not sure why omitting -fno-PIE is not a problem, but it works.
All pretty confusing. Are you going to send a cleaned up patch then?
I'm going to send out v2 with updated commit message.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 45 lines · Wei Liu
Quoted 35 lines · Jan Beulich
Quoted 35 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 13:43, <[email protected]> wrote:
Quoted 22 lines · Jan Beulich
Quoted 8 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 12:49, <[email protected]> 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 <[email protected]>Signed-off-by Jan Beulich <[email protected]>Signed-off-by Wei Liu <[email protected]>Quoted 6 lines
---
Cc: Jan Beulich <[email protected]>
Cc: Andrew Cooper <[email protected]>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.
Quoted 4 lines
tools/tests/x86_emulator/Makefile +0
-0@@ -98,7 +98,9 @@ asm: asm/%: asm ;Quoted 8 lines
tools/tests/x86_emulator/Makefile asm: · line 103
Quoted 4 lines
tools/tests/x86_emulator/Makefile +3
-1-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.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
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)?
Quoted 7 lines
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.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 57 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 15:01, <[email protected]> wrote:
Quoted 45 lines · Wei Liu
Quoted 35 lines · Jan Beulich
Quoted 35 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 13:43, <[email protected]> wrote:
Quoted 22 lines · Jan Beulich
Quoted 8 lines
Quoted 1 line
Quoted 1 line · On 25.09.17 at 12:49, <[email protected]> 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 <[email protected]>Signed-off-by Jan Beulich <[email protected]>Signed-off-by Wei Liu <[email protected]>Quoted 6 lines
---
Cc: Jan Beulich <[email protected]>
Cc: Andrew Cooper <[email protected]>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.
Quoted 4 lines
tools/tests/x86_emulator/Makefile +0
-0@@ -98,7 +98,9 @@ asm: asm/%: asm ;Quoted 8 lines
tools/tests/x86_emulator/Makefile asm: · line 103
Quoted 4 lines
tools/tests/x86_emulator/Makefile +3
-1-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.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
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)?
Quoted 7 lines
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:
Quoted 7 lines
(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
[email protected]
https://lists.xen.org/xen-devel
Quoted 6 lines · Jan Beulich
Quoted 6 lines
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
Quoted 6 lines
Quoted 4 lines
(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
That was a rather unfortunate typo. Sorry.
"The build rune is in fact using HOSTCC to link the executable, hence we need -fno-pie." Should be "we need -no-pie".
Quoted 2 lines
it choke on that one too?
No, it doesn't.
For gcc 4.6, -fno-pie is OK but -no-pie is not, because 4.6 already has -fno-pie.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel