From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Thu, 16 Jul 2015 08:54:06 +0200 Subject: [U-Boot] debug warning In-Reply-To: <55A6C35E.6000001@freescale.com> References: <55A6BC3F.9010003@freescale.com> <20150715222334.00f2ddca@lilith> <55A6C1C9.7090802@freescale.com> <55A6C35E.6000001@freescale.com> Message-ID: <20150716085406.757c06db@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello York, On Wed, 15 Jul 2015 13:32:30 -0700, York Sun wrote: > > > On 07/15/2015 01:29 PM, Simon Glass wrote: > > Hi York, > > > > On 15 July 2015 at 14:25, York Sun wrote: > >> > >> > >> On 07/15/2015 01:23 PM, Albert ARIBAUD wrote: > >>> Hello York, > >>> > >>> On Wed, 15 Jul 2015 13:02:07 -0700, York Sun > >>> wrote: > >>>> Simon, > >>>> > >>>> Did it happen to you with this warning? > >>>> > >>>> lib/fdtdec.c:108:4: warning: format ?%x? expects argument of type ?unsigned > >>>> int?, but argument 3 has type ?fdt_size_t? [-Wformat=] > >>>> debug("addr=%08lx, size=%08x\n", > >>>> ^ > >>>> > >>>> I think when we have 64-bit physical address, as defined in fdtdec.h, this debug > >>>> statement needs to be changed. I am thinking to change the typedef fdt_addr_t to > >>>> phys_addr_t, and fdt_size_t to phys_size_t. What do you say? > >>> > >>> I say there is no reason to change a type just because a printf format > >>> specifier is wrong for it when building for 64-bit. > >>> > >>> Is there a rationale apart from the format specifier error? > >>> > >>> If not, then What should be done is fix the specifier so that it is > >>> correct in both 32 and 64 bits. > >>> > >> > >> Albert, > >> > >> Let me send a RFC patch so you can comment on it. > > > > I'm not sure how to do what Albert is suggesting. > > > > I only thought of two ways, using #ifdef or changing the type as my RFC patch > suggests. There's a third one: changing the form of the format specifier according to the target's definition of the variable -- you do that once somewhere in a common header file and you're all set up everywhere else. See for instance how 'uint64_t' has such a format specifier PRIu64 #define-d in /usr/include/inttypes.h; whatever the definition of uint64_t, you can do a printf with it as follows: uint64_t var; ... printf("Value of var is " PRIu64 ".\n", var); (I learned this about a year ago while working on code that had to run on both a 64-bit Intel-core PC and a 32-bit ARM-core Beaglebone) The same technique can be used here and I strongly prefer it oer changing the type of the variable, because changing the type affects the function of *all* code that uses the variable (thus potentially modifying the board behavior), whereas changing the format specifier affects *only* the printf() code (thus not changing the board behavior except for debug code which, supposedly, it only *fixes*. > York Amicalement, -- Albert.