Re: [Qemu-devel] [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
malc wrote: On Tue, 30 Sep 2008, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt [EMAIL PROTECTED] *update* further debugging according to some requests revealed that ARCH_CFLAGS does not contain all CFLAGS that might be needed, especially those supplied via extra-cflags. Therefore people supplying things via extra-cflags instead of an environment variable might have had issues. This part i don't get, there are few more checks before/after hostlongbits where no CFLAGS are added to the $cc argument list. What makes hostlongbits selection special? Do people specify -m32/-m64 via --extra-cflags? it was there to ensure availability of the needed include paths to reach wordsize.h. But Hollis approach is much simpler, better and more reliable so never mind :-) A recent kvm merge with qemu brought code for 64bit power that broke cross compilation. The issue is caused by configure trying to execute target architecture binaries where configure is executed. Yes, i never thought about cross-compilation, my bad. np, now it's fixed - thanks for quickly applying it. I tried to change that detection so that it works withwithout cross compilation with only a small change and especially without an addtional configure command line switch. Including the bits/wordsize.h header a platform usually can check its wordsize and by doing that configure can check the hostlongbits without executing the binary. Instead it now stops after preprocessing stage which resolved the __WORDSIZE constant and retrieves that value. I don't like my new check style, but it is at least less broken than before. Another approach that was suggested was that qemu might end up needing something like asm-offsets in the kernel to manage architecture sizes etc. Comments and other approaches welcome. I think Hollis Blanchard's method is sound, Thank you for bringing this up. -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
malc wrote: On Tue, 30 Sep 2008, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt [EMAIL PROTECTED] *update* further debugging according to some requests revealed that ARCH_CFLAGS does not contain all CFLAGS that might be needed, especially those supplied via extra-cflags. Therefore people supplying things via extra-cflags instead of an environment variable might have had issues. This part i don't get, there are few more checks before/after hostlongbits where no CFLAGS are added to the $cc argument list. What makes hostlongbits selection special? Do people specify -m32/-m64 via --extra-cflags? it was there to ensure availability of the needed include paths to reach wordsize.h. But Hollis approach is much simpler, better and more reliable so never mind :-) A recent kvm merge with qemu brought code for 64bit power that broke cross compilation. The issue is caused by configure trying to execute target architecture binaries where configure is executed. Yes, i never thought about cross-compilation, my bad. np, now it's fixed - thanks for quickly applying it. I tried to change that detection so that it works withwithout cross compilation with only a small change and especially without an addtional configure command line switch. Including the bits/wordsize.h header a platform usually can check its wordsize and by doing that configure can check the hostlongbits without executing the binary. Instead it now stops after preprocessing stage which resolved the __WORDSIZE constant and retrieves that value. I don't like my new check style, but it is at least less broken than before. Another approach that was suggested was that qemu might end up needing something like asm-offsets in the kernel to manage architecture sizes etc. Comments and other approaches welcome. I think Hollis Blanchard's method is sound, Thank you for bringing this up. -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
From: Christian Ehrhardt [EMAIL PROTECTED]
*update*
further debugging according to some requests revealed that ARCH_CFLAGS does
not contain all CFLAGS that might be needed, especially those supplied via
extra-cflags. Therefore people supplying things via extra-cflags instead of an
environment variable might have had issues.
A recent kvm merge with qemu brought code for 64bit power that broke cross
compilation. The issue is caused by configure trying to execute target
architecture binaries where configure is executed.
I tried to change that detection so that it works withwithout cross
compilation with only a small change and especially without an addtional
configure command line switch. Including the bits/wordsize.h header a platform
usually can check its wordsize and by doing that configure can check the
hostlongbits without executing the binary. Instead it now stops after
preprocessing stage which resolved the __WORDSIZE constant and retrieves
that value.
I don't like my new check style, but it is at least less broken than before.
Another approach that was suggested was that qemu might end up needing
something like asm-offsets in the kernel to manage architecture sizes etc.
Comments and other approaches welcome.
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---
[diffstat]
configure | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
[diff]
diff --git a/qemu/configure b/qemu/configure
--- a/qemu/configure
+++ b/qemu/configure
@@ -685,14 +685,15 @@
# ppc specific hostlongbits selection
if test $cpu = powerpc ; then
cat $TMPC EOF
-int main(void){return sizeof(long);}
+#include bits/wordsize.h
+__WORDSIZE
EOF
-if $cc $ARCH_CFLAGS -o $TMPE $TMPC 2 /dev/null; then
-$TMPE
-case $? in
-4) hostlongbits=32;;
-8) hostlongbits=64;;
+if $cc $ARCH_CFLAGS $CFLAGS -E -o $TMPE.E $TMPC 2 /dev/null; then
+wordsize=`tail -n 1 ${TMPE}.E`
+case $wordsize in
+32) hostlongbits=32;;
+64) hostlongbits=64;;
*) echo Couldn't determine bits per long value; exit 1;;
esac
else
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
On Tue, 2008-09-30 at 11:10 +0200, [EMAIL PROTECTED] wrote:
diff --git a/qemu/configure b/qemu/configure
--- a/qemu/configure
+++ b/qemu/configure
@@ -685,14 +685,15 @@
# ppc specific hostlongbits selection
if test $cpu = powerpc ; then
cat $TMPC EOF
-int main(void){return sizeof(long);}
+#include bits/wordsize.h
+__WORDSIZE
EOF
-if $cc $ARCH_CFLAGS -o $TMPE $TMPC 2 /dev/null; then
-$TMPE
-case $? in
-4) hostlongbits=32;;
-8) hostlongbits=64;;
+if $cc $ARCH_CFLAGS $CFLAGS -E -o $TMPE.E $TMPC 2 /dev/null; then
+wordsize=`tail -n 1 ${TMPE}.E`
+case $wordsize in
+32) hostlongbits=32;;
+64) hostlongbits=64;;
*) echo Couldn't determine bits per long value; exit 1;;
esac
else
Yeah, trying to execute target-specific code is simply incompatible with
cross-compiling, so clearly this needs to be changed.
bits/wordsize.h might be too Linux-specific, not sure. Also, I worry
about the preprocessor being allowed to insert all the whitespace it
wants, so I'm not sure if you can assume that __WORDSIZE will be on the
last output line.
Instead you could use this:
$cc -E -dM - /dev/null | grep __powerpc64__
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
On Tue, 30 Sep 2008, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt [EMAIL PROTECTED] *update* further debugging according to some requests revealed that ARCH_CFLAGS does not contain all CFLAGS that might be needed, especially those supplied via extra-cflags. Therefore people supplying things via extra-cflags instead of an environment variable might have had issues. This part i don't get, there are few more checks before/after hostlongbits where no CFLAGS are added to the $cc argument list. What makes hostlongbits selection special? Do people specify -m32/-m64 via --extra-cflags? A recent kvm merge with qemu brought code for 64bit power that broke cross compilation. The issue is caused by configure trying to execute target architecture binaries where configure is executed. Yes, i never thought about cross-compilation, my bad. I tried to change that detection so that it works withwithout cross compilation with only a small change and especially without an addtional configure command line switch. Including the bits/wordsize.h header a platform usually can check its wordsize and by doing that configure can check the hostlongbits without executing the binary. Instead it now stops after preprocessing stage which resolved the __WORDSIZE constant and retrieves that value. I don't like my new check style, but it is at least less broken than before. Another approach that was suggested was that qemu might end up needing something like asm-offsets in the kernel to manage architecture sizes etc. Comments and other approaches welcome. I think Hollis Blanchard's method is sound, Thank you for bringing this up. -- mailto:[EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
On Tue, 30 Sep 2008, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt [EMAIL PROTECTED] The commit message of r5364, the revision which basically exists because of your posts, was somehow butchered and as such doesn't include any references, i'm very sorry about that. The above line was there in the commit message editing buffer, but then i somehow screwed it all up, probably when trying to reformat stuff suffling text around. Once again, i'm sorry. [..snip..] -- mailto:[EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
On Tue, 30 Sep 2008, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt [EMAIL PROTECTED] *update* further debugging according to some requests revealed that ARCH_CFLAGS does not contain all CFLAGS that might be needed, especially those supplied via extra-cflags. Therefore people supplying things via extra-cflags instead of an environment variable might have had issues. This part i don't get, there are few more checks before/after hostlongbits where no CFLAGS are added to the $cc argument list. What makes hostlongbits selection special? Do people specify -m32/-m64 via --extra-cflags? A recent kvm merge with qemu brought code for 64bit power that broke cross compilation. The issue is caused by configure trying to execute target architecture binaries where configure is executed. Yes, i never thought about cross-compilation, my bad. I tried to change that detection so that it works withwithout cross compilation with only a small change and especially without an addtional configure command line switch. Including the bits/wordsize.h header a platform usually can check its wordsize and by doing that configure can check the hostlongbits without executing the binary. Instead it now stops after preprocessing stage which resolved the __WORDSIZE constant and retrieves that value. I don't like my new check style, but it is at least less broken than before. Another approach that was suggested was that qemu might end up needing something like asm-offsets in the kernel to manage architecture sizes etc. Comments and other approaches welcome. I think Hollis Blanchard's method is sound, Thank you for bringing this up. -- mailto:[EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
