From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Evans Date: Thu, 08 Dec 2011 03:14:58 +0000 Subject: Re: [PATCH 05/28] kvm tools: 64-bit tidy; use PRIx64 when printf'ing Message-Id: <4EE02BB2.5090908@ozlabs.org> List-Id: References: <4EDD8E4D.5000309@ozlabs.org> <1323159238.3882.6.camel@lappy> <20111206082827.GA30062@elte.hu> <20111206100538.GA8178@bloggs.ozlabs.ibm.com> <20111206102428.GB15966@elte.hu> <4EDF0F60.8080301@ozlabs.org> <20111207081602.GA8023@elte.hu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Pekka Enberg Cc: Ingo Molnar , Paul Mackerras , Sasha Levin , kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, Pekka Enberg On 08/12/11 04:14, Pekka Enberg wrote: > On Wed, 7 Dec 2011, Ingo Molnar wrote: > >> >> * Matt Evans wrote: >> >>>>> [...] I haven't looked closely at Matt's >>>>> patches, but it should be possible to use [un]signed long long >>>>> for the u64/s64 types, I would think. >>>> >>>> In tools/kvm/ we are using our own u64/s64 definitions, not >>>> glibc's, so i think it should be fine - as long as we don't pick >>>> up int-l64.h accidentally via the >>>> arch/powerpc/include/asm/types.h exception for user-space. >>> >>> That's what's happening here; we're __powerpc64__ and >>> !__KERNEL__, tools/kvm/include/linux/types.h includes >>> asm/types.h so gets the int-l64.h definition of __u64, as >>> above. :/ >>> >>> builtin-run.c:389: error: format `%llx' expects type `long >>> long unsigned int', but argument 2 has type `u64' >> >> So either define __KERNEL__ or patch a __NEW_USERSPACE__ define >> into power/asm/types.h and use it - if the PowerPC folks agree >> with that approach. >> >> Sane userspace should not be prevented from using the same sane >> types the kernel is already using :-) > > How does perf handle this? I'm sure it has the exact same issue, doesn't > it? It does; ironically it uses PRIblah, so I had followed its example. Cheers, Matt