From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Ehrhardt Date: Wed, 01 Oct 2008 12:26:32 +0000 Subject: Re: [Qemu-devel] [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits Message-Id: <48E36C78.9020605@linux.vnet.ibm.com> List-Id: References: <1222765817-26552-1-git-send-email-ehrhardt@linux.vnet.ibm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: malc Cc: qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org, kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org, hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org malc wrote: > On Tue, 30 Sep 2008, ehrhardt@linux.vnet.ibm.com wrote: > >> From: Christian Ehrhardt >> >> *update* >> further debugging according to some requests revealed that=20 >> ARCH_CFLAGS does >> not contain all CFLAGS that might be needed, especially those=20 >> supplied via >> extra-cflags. Therefore people supplying things via extra-cflags=20 >> instead of an >> environment variable might have had issues. > > This part i don't get, there are few more checks before/after=20 > 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=20 wordsize.h. But Hollis approach is much simpler, better and more reliable so never=20 mind :-) >> >> A recent kvm merge with qemu brought code for 64bit power that broke=20 >> 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 with&without cross >> compilation with only a small change and especially without an addtional >> configure command line switch. Including the bits/wordsize.h header a=20 >> 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=20 >> before. >> Another approach that was suggested was that qemu might end up needing >> something like asm-offsets in the kernel to manage architecture sizes=20 >> etc. >> Comments and other approaches welcome. >> > > I think Hollis Blanchard's method is sound, > > Thank you for bringing this up. > --=20 Gr=FCsse / regards,=20 Christian Ehrhardt IBM Linux Technology Center, Open Virtualization From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Ehrhardt Subject: Re: [Qemu-devel] [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2 Date: Wed, 01 Oct 2008 14:26:32 +0200 Message-ID: <48E36C78.9020605@linux.vnet.ibm.com> References: <1222765817-26552-1-git-send-email-ehrhardt@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org, kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org, hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org To: malc Return-path: In-Reply-To: Sender: kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: kvm.vger.kernel.org malc wrote: > On Tue, 30 Sep 2008, ehrhardt-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org wrote: > >> From: Christian Ehrhardt >> >> *update* >> further debugging according to some requests revealed that=20 >> ARCH_CFLAGS does >> not contain all CFLAGS that might be needed, especially those=20 >> supplied via >> extra-cflags. Therefore people supplying things via extra-cflags=20 >> instead of an >> environment variable might have had issues. > > This part i don't get, there are few more checks before/after=20 > hostlongbits where no CFLAGS are added to the $cc argument list. What > makes hostlongbits selection "special"? Do people specify -m32/-m64 v= ia > --extra-cflags? > it was there to ensure availability of the needed include paths to reac= h=20 wordsize.h. But Hollis approach is much simpler, better and more reliable so never=20 mind :-) >> >> A recent kvm merge with qemu brought code for 64bit power that broke= =20 >> cross >> compilation. The issue is caused by configure trying to execute targ= et >> 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 with&without cross >> compilation with only a small change and especially without an addti= onal >> configure command line switch. Including the bits/wordsize.h header = a=20 >> platform >> usually can check its wordsize and by doing that configure can check= the >> hostlongbits without executing the binary. Instead it now stops afte= r >> preprocessing stage which resolved the __WORDSIZE constant and retri= eves >> that value. >> >> I don't like my new check style, but it is at least less broken than= =20 >> before. >> Another approach that was suggested was that qemu might end up needi= ng >> something like asm-offsets in the kernel to manage architecture size= s=20 >> etc. >> Comments and other approaches welcome. >> > > I think Hollis Blanchard's method is sound, > > Thank you for bringing this up. > --=20 Gr=FCsse / regards,=20 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html