From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Evans Subject: Re: [PATCH 05/28] kvm tools: 64-bit tidy; use PRIx64 when printf'ing u64s and link appropriately Date: Wed, 07 Dec 2011 18:01:52 +1100 Message-ID: <4EDF0F60.8080301@ozlabs.org> References: <4EDD8E4D.5000309@ozlabs.org> <1323159238.3882.6.camel@lappy> <20111206082827.GA30062@elte.hu> <20111206100538.GA8178@bloggs.ozlabs.ibm.com> <20111206102428.GB15966@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Mackerras , Sasha Levin , kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, Pekka Enberg To: Ingo Molnar Return-path: In-Reply-To: <20111206102428.GB15966@elte.hu> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Hi Ingo, On 06/12/11 21:24, Ingo Molnar wrote: > > * Paul Mackerras wrote: > >> On Tue, Dec 06, 2011 at 09:28:27AM +0100, Ingo Molnar wrote: >>> >>> * Sasha Levin wrote: >>> >>>> Ingo actually got us to remove all the PRI* specifiers, but >>>> that was back when we only did x86 :) >>>> >>>> Ingo, does it make sense to use them now when we support >>>> different architectures? >>> >>> Not at all - ppc should use a sane u64/s64 definition, i.e. >>> int-ll64.h instead of the int-l64.h crap. >>> >>> The powerpc maintainers indicated that they'd fix that, a couple >>> of years ago, but nothing appears to have come out of that. >> >> We changed it for the kernel, but not for userspace (i.e. >> glibc) because of concerns about possibly breaking existing >> userspace programs. [...] > > Indeed, you do: > > #if defined(__powerpc64__) && !defined(__KERNEL__) > # include > #else > # include > #endif > > which correctly uses int-ll64.h everywhere except 64-bit > userspace inclusions. So i take back my 'nothing appears to have > come out of that' comment - it's all nicely fixed! > >> [...] 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' etc. etc. Cheers, Matt