Provide inttypes.h to avoid 32/64 bit problems with printf()
Subsystems (4)
cover Provide inttypes.h to avoid 32/64 bit problems with printf()
In quite a few situations we have to print a 64-bit value. Unfortunately the type used for 64-bit can vary depending on the machine. For 64-bit machines it might be 'long' and for 32-bit machines it might be 'long long'.
As a result we need to use either %ld or %lld depending on the architecture. Add the inttypes.h header file to provide defines for this and clean up the code to use these defines in a few places.
The stdint.h file is bundled with recent versions of gcc and it is generally better to use this rather than our own versions. Add an option to use the internal stdint.h file.
Gabe Black (2):
Provide option to avoid defining a custom version of uintptr_t. Add some standard headers external code might need
Simon Glass (8):
ext4: Use inttypes for printf() string
Use uint64_t for time types
Use uint64_t instead of u64 in put_dec()
Tidy up data sizes and function comment in display_options
x86: Use correct printf() format string for uintptr_t
scsi: Use correct printf() format string for uintptr_t
usb: Use correct printf() format string for uintptr_t
test: Add a simple test to detected warnings with uint64_t, uintptr_t
README | 5 + arch/sandbox/include/asm/types.h | 5 + arch/x86/include/asm/types.h | 5 + arch/x86/lib/relocate.c | 3 +- common/cmd_scsi.c | 9 +- common/usb_storage.c | 11 +- config.mk | 5 + fs/ext4/ext4_common.c | 3 +- include/common.h | 19 ++- include/compiler.h | 11 +- include/inttypes.h | 287 +++++++++++++++++++++++++++++++++++++++ include/linux/types.h | 9 +- include/stdlib.h | 12 ++ lib/display_options.c | 14 +- lib/time.c | 12 +- lib/vsprintf.c | 2 +- test/stdint/int-types.c | 13 ++ test/stdint/test-includes.sh | 58 ++++++++ 18 files changed, 450 insertions(+), 33 deletions(-) create mode 100644 include/inttypes.h create mode 100644 include/stdlib.h create mode 100644 test/stdint/int-types.c create mode 100755 test/stdint/test-includes.sh
Signature · 1 line
2.1.0.rc2.206.gedb03e5
PATCH 1/10 Provide option to avoid defining a custom version of uintptr_t.
From: Gabe Black <[email protected]>
There's a definition in stdint.h (provided by gcc) which will be more correct if available.
Define CONFIG_USE_STDINT to use this feature, or USE_STDINT=1 on the 'make' commmand.
This adjusts the settings for x86 and sandbox, with both have 64-bit options.
Rewritten to be an option, since stdint.h is often available only in glibc. Changed to preserve a clear boundary between stdint and non-stdint
---
README | 5 +++++ arch/sandbox/include/asm/types.h | 5 +++++ arch/x86/include/asm/types.h | 5 +++++ config.mk | 5 +++++ include/compiler.h | 11 ++++++++--- include/linux/types.h | 9 ++++++++- 6 files changed, 36 insertions(+), 4 deletions(-)
README +5 -0
@@ -4055,6 +4055,11 @@ Configuration Settings: be asserted. See doc/README.omap-reset-time for details on how the value can be calulated on a given board. +- CONFIG_USE_STDINT + If stdint.h is available with your toolchain you can define this + option to enable it. You can provide option 'USE_STDINT=1' when + building U-Boot to enable this. + The following definitions that deal with the placement and management of environment data (variable area); in general, we support the following configurations:
arch/sandbox/include/asm/types.h +5 -0
@@ -42,8 +42,13 @@ typedef unsigned short u16;typedef signed int s32 ;typedef unsigned int u32 ; +#if !defined(CONFIG_USE_STDINT ) || !defined(__INT64_TYPE__)typedef signed long long s64 ;typedef unsigned long long u64 ; +#else +typedef __INT64_TYPE__ s64 ; +typedef __UINT64_TYPE__ u64 ; +#endif #define BITS_PER_LONG CONFIG_SANDBOX_BITS_PER_LONG
arch/x86/include/asm/types.h +5 -0
@@ -36,8 +36,13 @@ typedef unsigned short u16;typedef signed int s32 ;typedef unsigned int u32 ; +#if !defined(CONFIG_USE_STDINT ) || !defined(__INT64_TYPE__)typedef signed long long s64 ;typedef unsigned long long u64 ; +#else +typedef __INT64_TYPE__ s64 ; +typedef __UINT64_TYPE__ u64 ; +#endif #define BITS_PER_LONG 32
config.mk +5 -0
@@ -57,6 +57,11 @@ ifdef FTRACE PLATFORM_CPPFLAGS += -finstrument-functions -DFTRACE endif +# Allow use of stdint.h if available +ifneq ($(USE_STDINT),) +PLATFORM_CPPFLAGS += -DCONFIG_USE_STDINT +endif + ######################################################################### RELFLAGS := $(PLATFORM_RELFLAGS)
include/compiler.h +8 -3
@@ -112,6 +112,14 @@ typedef unsigned int uint;#else /* !USE_HOSTCC */ +#ifdef CONFIG_USE_STDINT +/* Provided by gcc. */ +#include <stdint.h> +#else +/* Type for `void *' pointers. */ +typedef unsigned long int uintptr_t ; +#endif +#include <linux/string.h> #include <linux/types.h> #include <asm/byteorder.h>
@@ -128,9 +136,6 @@ typedef unsigned int uint;#define __WORDSIZE 32#endif -/* Type for `void *' pointers. */ -typedef unsigned long int uintptr_t ; -#endif /* USE_HOSTCC */ #define likely (x) __builtin_expect(!!(x), 1)
include/linux/types.h +8 -1
@@ -104,7 +104,8 @@ typedef __u8 uint8_t;typedef __u16 uint16_t ;typedef __u32 uint32_t ; -#if defined(__GNUC__) && !defined(__STRICT_ANSI__) +#if defined(__GNUC__) && !defined(__STRICT_ANSI__) && \ + (!defined(CONFIG_USE_STDINT ) || !defined(__INT64_TYPE__))typedef __u64 uint64_t ;typedef __u64 u_int64_t ;typedef __s64 int64_t ;
@@ -112,6 +113,12 @@ typedef __s64 int64_t;#endif /* __KERNEL_STRICT_NAMES */ +#if defined(CONFIG_USE_STDINT ) && defined(__INT64_TYPE__) +typedef __UINT64_TYPE__ uint64_t ; +typedef __UINT64_TYPE__ u_int64_t ; +typedef __INT64_TYPE__ int64_t ; +#endif +/* * Below are truly Linux-specific types that should never collide with * any application/library that wants linux/types.h.
Signature · 1 line
2.1.0.rc2.206.gedb03e5
PATCH 1/10 Provide option to avoid defining a custom version of uintptr_t.
Quoted 10 lines · Simon Glass
From: Gabe Black <[email protected]>
There's a definition in
stdint.h(provided by gcc) which will be more correct if available.Define
CONFIG_USE_STDINTto use this feature, or USE_STDINT=1 on the 'make' commmand.This adjusts the settings for x86 and sandbox, with both have 64-bit options.
Quoted 7 lines
Signed-off-by Gabe Black <[email protected]>Reviewed-by Gabe Black <[email protected]>Tested-by Gabe Black <[email protected]>Reviewed-by Bill Richardson <[email protected]>Rewritten to be an option, since
stdint.his often available only in glibc. Changed to preserve a clear boundary between stdint and non-stdintSigned-off-by Simon Glass <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141027/8c94931c/attachment.pgp>
PATCH 2/10 Add some standard headers external code might need
In reply to Simon GlassFrom: Gabe Black <[email protected]>
inttypes.h defines format specifiers for printf which work with data types of particular sizes. stdlib.h is currently just a passthrough to malloc.h which has declarations of the various *alloc functions.
Add the required #define to common.h so that these printf format specifiers will be made available.
(Replaced with a GPL version from glibc)
---
include/common.h | 3 + include/inttypes.h | 287 +++++++++++++++++++++++++++++++++++++++++++++++++++++ include/stdlib.h | 12 +++ 3 files changed, 302 insertions(+) create mode 100644 include/inttypes.h create mode 100644 include/stdlib.h
include/common.h +3 -0
@@ -86,6 +86,9 @@ typedef volatile unsigned char vu_char;#include <flash.h> #include <image.h> +/* Bring in printf format macros if inttypes.h is included */ +#define __STDC_FORMAT_MACROS +#ifdef __LP64__#define CONFIG_SYS_SUPPORT_64BIT_DATA #endif
include/inttypes.h new file +287 -0
287 lines not on this page · raw message
include/stdlib.h new file +12 -0
@@ -0,0 +1,12 @@ +/* +* Copyright (C) 2013 Google Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef __STDLIB_H_ +#define __STDLIB_H_ + +#include <malloc.h> + +#endif /* __STDLIB_H_ */
Signature · 1 line
2.1.0.rc2.206.gedb03e5
PATCH 2/10 Add some standard headers external code might need
Quoted 9 lines · Simon Glass
From: Gabe Black <[email protected]>
inttypes.hdefines format specifiers for printf which work with data types of particular sizes.stdlib.his currently just a passthrough tomalloc.hwhich has declarations of the various *alloc functions.Add the required #define to
common.hso that these printf format specifiers will be made available.
Quoted 6 lines
Signed-off-by Gabe Black <[email protected]>Reviewed-by Gabe Black <[email protected]>Tested-by Gabe Black <[email protected]>Reviewed-by Bill Richardson <[email protected]>Signed-off-by Simon Glass <[email protected]>(Replaced with a GPL version from glibc)
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141027/e8fde6df/attachment.pgp>
PATCH 2/10 Add some standard headers external code might need
In reply to Simon GlassHi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 16 lines
From: Gabe Black <[email protected]>
inttypes.hdefines format specifiers for printf which work with data types of particular sizes.stdlib.his currently just a passthrough tomalloc.hwhich has declarations of the various *alloc functions.Add the required #define to
common.hso that these printf format specifiers will be made available.Signed-off-by Gabe Black <[email protected]>Reviewed-by Gabe Black <[email protected]>Tested-by Gabe Black <[email protected]>Reviewed-by Bill Richardson <[email protected]>Signed-off-by Simon Glass <[email protected]>(Replaced with a GPL version from glibc)
[snip]
Quoted 19 lines
include/stdlib.h new file +12
-1@@ -0,0 +1,12 @@ +/* +* Copyright (C) 2013 Google Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef __STDLIB_H_ +#define __STDLIB_H_ + +#include <malloc.h> + +#endif /* __STDLIB_H_ */ --
Quoted 1 line
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Why do we need include/stdlib.h ?
Signature · 2 lines
Best Regards Masahiro Yamada
PATCH 2/10 Add some standard headers external code might need
Hi Masahiro,
Quoted 46 lines · Masahiro YAMADA
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 16 lines
From: Gabe Black <[email protected]>
inttypes.hdefines format specifiers for printf which work with data types of particular sizes.stdlib.his currently just a passthrough tomalloc.hwhich has declarations of the various *alloc functions.Add the required #define to
common.hso that these printf format specifiers will be made available.Signed-off-by Gabe Black <[email protected]>Reviewed-by Gabe Black <[email protected]>Tested-by Gabe Black <[email protected]>Reviewed-by Bill Richardson <[email protected]>Signed-off-by Simon Glass <[email protected]>(Replaced with a GPL version from glibc)
[snip]
Quoted 19 lines
include/stdlib.h new file +12
-1@@ -0,0 +1,12 @@ +/* +* Copyright (C) 2013 Google Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef __STDLIB_H_ +#define __STDLIB_H_ + +#include <malloc.h> + +#endif /* __STDLIB_H_ */ --Quoted 1 line
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Quoted 1 line
Why do we need
include/stdlib.h?
This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally stdlib.h defines malloc() and friends.
Regards,
Simon
PATCH 2/10 Add some standard headers external code might need
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass <[email protected]>:
Quoted 49 lines
Hi Masahiro,
Quoted 46 lines · Masahiro YAMADA
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 16 lines
From: Gabe Black <[email protected]>
inttypes.hdefines format specifiers for printf which work with data types of particular sizes.stdlib.his currently just a passthrough tomalloc.hwhich has declarations of the various *alloc functions.Add the required #define to
common.hso that these printf format specifiers will be made available.Signed-off-by Gabe Black <[email protected]>Reviewed-by Gabe Black <[email protected]>Tested-by Gabe Black <[email protected]>Reviewed-by Bill Richardson <[email protected]>Signed-off-by Simon Glass <[email protected]>(Replaced with a GPL version from glibc)
[snip]
Quoted 19 lines
include/stdlib.h new file +12
-1@@ -0,0 +1,12 @@ +/* +* Copyright (C) 2013 Google Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef __STDLIB_H_ +#define __STDLIB_H_ + +#include <malloc.h> + +#endif /* __STDLIB_H_ */ --Quoted 1 line
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Quoted 5 lines
Quoted 1 line
Why do we need
include/stdlib.h?This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally
stdlib.hdefinesmalloc()and friends.
I am not happy about this.
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.h shouldn't appear in bare metal code.
Signature · 2 lines
Best Regards Masahiro Yamada
PATCH 2/10 Add some standard headers external code might need
Hi Masahiro,
Quoted 59 lines · Masahiro YAMADA
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass <[email protected]>:
Quoted 49 lines
Hi Masahiro,
Quoted 46 lines · Masahiro YAMADA
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 16 lines
From: Gabe Black <[email protected]>
inttypes.hdefines format specifiers for printf which work with data types of particular sizes.stdlib.his currently just a passthrough tomalloc.hwhich has declarations of the various *alloc functions.Add the required #define to
common.hso that these printf format specifiers will be made available.Signed-off-by Gabe Black <[email protected]>Reviewed-by Gabe Black <[email protected]>Tested-by Gabe Black <[email protected]>Reviewed-by Bill Richardson <[email protected]>Signed-off-by Simon Glass <[email protected]>(Replaced with a GPL version from glibc)
[snip]
Quoted 19 lines
include/stdlib.h new file +12
-1@@ -0,0 +1,12 @@ +/* +* Copyright (C) 2013 Google Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef __STDLIB_H_ +#define __STDLIB_H_ + +#include <malloc.h> + +#endif /* __STDLIB_H_ */ --Quoted 1 line
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Quoted 5 lines
Quoted 1 line
Why do we need
include/stdlib.h?This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally
stdlib.hdefinesmalloc()and friends.
Quoted 6 lines
I am not happy about this.
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.hshouldn't appear in bare metal code.
That's right, we don't want to include this in U-Boot itself. But if you look at things in tools/ they include stdlib.h. With this header available, we can more easily compile external code into U-Boot.
Regards,
Simon
PATCH 2/10 Add some standard headers external code might need
Hello Simon,
Quoted 60 lines · Simon Glass
Hi Masahiro,
Quoted 57 lines · Masahiro YAMADA
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass <[email protected]>:
Quoted 47 lines
Hi Masahiro,
Quoted 44 lines · Masahiro YAMADA
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 16 lines
From: Gabe Black <[email protected]>
inttypes.hdefines format specifiers for printf which work with data types of particular sizes.stdlib.his currently just a passthrough tomalloc.hwhich has declarations of the various *alloc functions.Add the required #define to
common.hso that these printf format specifiers will be made available.Signed-off-by Gabe Black <[email protected]>Reviewed-by Gabe Black <[email protected]>Tested-by Gabe Black <[email protected]>Reviewed-by Bill Richardson <[email protected]>Signed-off-by Simon Glass <[email protected]>(Replaced with a GPL version from glibc)
[snip]
Quoted 19 lines
include/stdlib.h new file +12
-1@@ -0,0 +1,12 @@ +/* +* Copyright (C) 2013 Google Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef __STDLIB_H_ +#define __STDLIB_H_ + +#include <malloc.h> + +#endif /* __STDLIB_H_ */ --Quoted 1 line
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Quoted 4 lines
Quoted 1 line
Why do we need
include/stdlib.h?This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally
stdlib.hdefinesmalloc()and friends.I am not happy about this.
Quoted 7 lines
Quoted 4 lines
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.hshouldn't appear in bare metal code.That's right, we don't want to include this in U-Boot itself. But if you look at things in
tools/they includestdlib.h. With this header available, we can more easily compile external code into U-Boot.
So is it intended as fallback if the host doesn't have a stdlib.h?
Regards,
Jeroen
PATCH 2/10 Add some standard headers external code might need
Hi,
Quoted 81 lines · Jeroen Hofstee
Hello Simon,
Quoted 77 lines · Simon Glass
Hi Masahiro,
Quoted 72 lines · Masahiro YAMADA
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass <[email protected]>:
Quoted 56 lines
Hi Masahiro,
Quoted 51 lines · Masahiro YAMADA
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 20 lines
From: Gabe Black <[email protected]>
inttypes.hdefines format specifiers for printf which work with data types of
particular sizes.stdlib.his currently just a passthrough tomalloc.hwhich
has declarations of the various *alloc functions.Add the required #define to
common.hso that these printf format specifiers
will be made available.Signed-off-by Gabe Black <[email protected]>Reviewed-by Gabe Black <[email protected]>Tested-by Gabe Black <[email protected]>Reviewed-by Bill Richardson <[email protected]>Signed-off-by Simon Glass <[email protected]>(Replaced with a GPL version from glibc)
[snip]
Quoted 20 lines
include/stdlib.h new file +12
-1@@ -0,0 +1,12 @@ +/* +* Copyright (C) 2013 Google Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef __STDLIB_H_ +#define __STDLIB_H_ + +#include <malloc.h> + +#endif /* __STDLIB_H_ */ --Quoted 1 line
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Quoted 5 lines
Quoted 1 line
Why do we need
include/stdlib.h?This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally
stdlib.hdefinesmalloc()and friends.I am not happy about this.
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
stdlib.hshouldn't appear in bare metal code.That's right, we don't want to include this in U-Boot itself. But if you look at things in
tools/they includestdlib.h. With this header available, we can more easily compile external code into U-Boot.So is it intended as fallback if the host doesn't have a
stdlib.h?
Not really, more that for things that expect that header (and inttypes.h which was also added) they can get it without needing special #ifdefs for U-Boot.
Regards,
Simon
PATCH 2/10 Add some standard headers external code might need
Hi Simon,
2014-10-29 3:24 GMT+09:00 Simon Glass <[email protected]>:
Quoted 91 lines
Hi,
Quoted 88 lines · Jeroen Hofstee
Hello Simon,
Quoted 82 lines · Simon Glass
Hi Masahiro,
Quoted 67 lines · Masahiro YAMADA
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass <[email protected]>:
Quoted 56 lines
Hi Masahiro,
Quoted 51 lines · Masahiro YAMADA
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 20 lines
From: Gabe Black <[email protected]>
inttypes.hdefines format specifiers for printf which work with data types of
particular sizes.stdlib.his currently just a passthrough tomalloc.hwhich
has declarations of the various *alloc functions.Add the required #define to
common.hso that these printf format specifiers
will be made available.Signed-off-by Gabe Black <[email protected]>Reviewed-by Gabe Black <[email protected]>Tested-by Gabe Black <[email protected]>Reviewed-by Bill Richardson <[email protected]>Signed-off-by Simon Glass <[email protected]>(Replaced with a GPL version from glibc)
[snip]
Quoted 20 lines
include/stdlib.h new file +12
-1@@ -0,0 +1,12 @@ +/* +* Copyright (C) 2013 Google Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef __STDLIB_H_ +#define __STDLIB_H_ + +#include <malloc.h> + +#endif /* __STDLIB_H_ */ --Quoted 1 line
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Quoted 5 lines
Quoted 1 line
Why do we need
include/stdlib.h?This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally
stdlib.hdefinesmalloc()and friends.Quoted 6 lines
I am not happy about this.
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.hshouldn't appear in bare metal code.That's right, we don't want to include this in U-Boot itself. But if you look at things in
tools/they includestdlib.h. With this header available, we can more easily compile external code into U-Boot.
Quoted 6 lines
Quoted 1 line
So is it intended as fallback if the host doesn't have a
stdlib.h?Not really, more that for things that expect that header (and
inttypes.hwhich was also added) they can get it without needing special #ifdefs for U-Boot.
Sorry, I still don't get it.
Could you explain user cases?
Signature · 2 lines
Best Regards Masahiro Yamada
PATCH 2/10 Add some standard headers external code might need
Hi Masahiro,
Quoted 96 lines · Masahiro YAMADA
Hi Simon,
2014-10-29 3:24 GMT+09:00 Simon Glass <[email protected]>:
Quoted 93 lines
Hi,
Quoted 89 lines · Jeroen Hofstee
Hello Simon,
Quoted 74 lines · Simon Glass
Hi Masahiro,
Quoted 69 lines · Masahiro YAMADA
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass <[email protected]>:
Quoted 56 lines
Hi Masahiro,
Quoted 51 lines · Masahiro YAMADA
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 20 lines
From: Gabe Black <[email protected]>
inttypes.hdefines format specifiers for printf which work with data types of
particular sizes.stdlib.his currently just a passthrough tomalloc.hwhich
has declarations of the various *alloc functions.Add the required #define to
common.hso that these printf format specifiers
will be made available.Signed-off-by Gabe Black <[email protected]>Reviewed-by Gabe Black <[email protected]>Tested-by Gabe Black <[email protected]>Reviewed-by Bill Richardson <[email protected]>Signed-off-by Simon Glass <[email protected]>(Replaced with a GPL version from glibc)
[snip]
Quoted 20 lines
include/stdlib.h new file +12
-1@@ -0,0 +1,12 @@ +/* +* Copyright (C) 2013 Google Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef __STDLIB_H_ +#define __STDLIB_H_ + +#include <malloc.h> + +#endif /* __STDLIB_H_ */ --Quoted 1 line
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Quoted 5 lines
Quoted 1 line
Why do we need
include/stdlib.h?This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally
stdlib.hdefinesmalloc()and friends.I am not happy about this.
Quoted 8 lines
Quoted 4 lines
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.hshouldn't appear in bare metal code.That's right, we don't want to include this in U-Boot itself. But if you look at things in
tools/they includestdlib.h. With this header available, we can more easily compile external code into U-Boot.So is it intended as fallback if the host doesn't have a
stdlib.h?
Quoted 8 lines
Quoted 4 lines
Not really, more that for things that expect that header (and
inttypes.hwhich was also added) they can get it without needing special #ifdefs for U-Boot.Sorry, I still don't get it.
Could you explain user cases?
If you have a C file which has '#include <stdlib.h> in it, because it builds in another project as well as U-Boot, and needs mallloc(), then you want to build it with U-Boot and include <common.h>, etc. then you need U-Boot to have stdlib.h, or add a dummy stdlib.h in that project. I am trying to make is easier for this case. This is a minor point, but little fish-hooks can be frustrating.
Regards,
Simon
PATCH 2/10 Add some standard headers external code might need
Hi Simon,
Quoted 108 lines · On Wed, 29 Oct 2014 19:43:26 -0600 Simon Glass <[email protected]> wrote:
Hi Masahiro,
Quoted 96 lines · Masahiro YAMADA
Hi Simon,
2014-10-29 3:24 GMT+09:00 Simon Glass <[email protected]>:
Quoted 93 lines
Hi,
Quoted 89 lines · Jeroen Hofstee
Hello Simon,
Quoted 74 lines · Simon Glass
Hi Masahiro,
Quoted 69 lines · Masahiro YAMADA
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass <[email protected]>:
Quoted 56 lines
Hi Masahiro,
Quoted 51 lines · Masahiro YAMADA
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 20 lines
From: Gabe Black <[email protected]>
inttypes.hdefines format specifiers for printf which work with data types of
particular sizes.stdlib.his currently just a passthrough tomalloc.hwhich
has declarations of the various *alloc functions.Add the required #define to
common.hso that these printf format specifiers
will be made available.Signed-off-by Gabe Black <[email protected]>Reviewed-by Gabe Black <[email protected]>Tested-by Gabe Black <[email protected]>Reviewed-by Bill Richardson <[email protected]>Signed-off-by Simon Glass <[email protected]>(Replaced with a GPL version from glibc)
[snip]
Quoted 20 lines
include/stdlib.h new file +12
-1@@ -0,0 +1,12 @@ +/* +* Copyright (C) 2013 Google Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef __STDLIB_H_ +#define __STDLIB_H_ + +#include <malloc.h> + +#endif /* __STDLIB_H_ */ --Quoted 1 line
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Quoted 5 lines
Quoted 1 line
Why do we need
include/stdlib.h?This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally
stdlib.hdefinesmalloc()and friends.I am not happy about this.
Quoted 8 lines
Quoted 4 lines
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.hshouldn't appear in bare metal code.That's right, we don't want to include this in U-Boot itself. But if you look at things in
tools/they includestdlib.h. With this header available, we can more easily compile external code into U-Boot.So is it intended as fallback if the host doesn't have a
stdlib.h?Quoted 8 lines
Quoted 4 lines
Not really, more that for things that expect that header (and
inttypes.hwhich was also added) they can get it without needing special #ifdefs for U-Boot.Sorry, I still don't get it.
Could you explain user cases?
Quoted 7 lines
If you have a C file which has '#include <
stdlib.h> in it, because it builds in another project as well as U-Boot, and needsmallloc(), then you want to build it with U-Boot and include <common.h>, etc. then you need U-Boot to havestdlib.h, or add a dummystdlib.hin that project. I am trying to make is easier for this case. This is a minor point, but little fish-hooks can be frustrating.
I understand what you want to do,
but I am not sure if this is a right decision.
Mixing the same header name sometimes causes a mess.
Best Regards
Masahiro Yamada
PATCH 2/10 Add some standard headers external code might need
Hi Masahiro,
Quoted 123 lines · Masahiro Yamada
Hi Simon,
Quoted 108 lines · On Wed, 29 Oct 2014 19:43:26 -0600 Simon Glass <[email protected]> wrote:
Hi Masahiro,
Quoted 96 lines · Masahiro YAMADA
Hi Simon,
2014-10-29 3:24 GMT+09:00 Simon Glass <[email protected]>:
Quoted 93 lines
Hi,
Quoted 89 lines · Jeroen Hofstee
Hello Simon,
Quoted 74 lines · Simon Glass
Hi Masahiro,
Quoted 69 lines · Masahiro YAMADA
Hi Simon,
2014-10-29 1:29 GMT+09:00 Simon Glass <[email protected]>:
Quoted 56 lines
Hi Masahiro,
Quoted 51 lines · Masahiro YAMADA
Hi Gabe, Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 20 lines
From: Gabe Black <[email protected]>
inttypes.hdefines format specifiers for printf which work with data types of
particular sizes.stdlib.his currently just a passthrough tomalloc.hwhich
has declarations of the various *alloc functions.Add the required #define to
common.hso that these printf format specifiers
will be made available.Signed-off-by Gabe Black <[email protected]>Reviewed-by Gabe Black <[email protected]>Tested-by Gabe Black <[email protected]>Reviewed-by Bill Richardson <[email protected]>Signed-off-by Simon Glass <[email protected]>(Replaced with a GPL version from glibc)
[snip]
Quoted 20 lines
include/stdlib.h new file +12
-1@@ -0,0 +1,12 @@ +/* +* Copyright (C) 2013 Google Inc. +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#ifndef __STDLIB_H_ +#define __STDLIB_H_ + +#include <malloc.h> + +#endif /* __STDLIB_H_ */ --Quoted 1 line
2.1.0.rc2.206.gedb03e5
This patch is not clear to me.
Quoted 5 lines
Quoted 1 line
Why do we need
include/stdlib.h?This makes the U-Boot environment more similar to that used by other software, so we can more easily build it without lots of glue files. Normally
stdlib.hdefinesmalloc()and friends.I am not happy about this.
Quoted 8 lines
Quoted 4 lines
Our right direction is to make U-Boot environment more similar to the Kernel, I think.
stdlib.hshouldn't appear in bare metal code.That's right, we don't want to include this in U-Boot itself. But if you look at things in
tools/they includestdlib.h. With this header available, we can more easily compile external code into U-Boot.So is it intended as fallback if the host doesn't have a
stdlib.h?Quoted 8 lines
Quoted 4 lines
Not really, more that for things that expect that header (and
inttypes.hwhich was also added) they can get it without needing special #ifdefs for U-Boot.Sorry, I still don't get it.
Could you explain user cases?Quoted 7 lines
If you have a C file which has '#include <
stdlib.h> in it, because it builds in another project as well as U-Boot, and needsmallloc(), then you want to build it with U-Boot and include <common.h>, etc. then you need U-Boot to havestdlib.h, or add a dummystdlib.hin that project. I am trying to make is easier for this case. This is a minor point, but little fish-hooks can be frustrating.
Quoted 4 lines
I understand what you want to do,
but I am not sure if this is a right decision.Mixing the same header name sometimes causes a mess.
That's true although I don't really see a big issue here.
IMO image.c and the like suffer from having two sets of headers - one for building in U-Boot and one for building outside. I thought maybe the solution was do have a section in common.h to deal with the differences, but then when I looked more I wasn't sure it was an improvement...
Regards,
Simon
PATCH 3/10 ext4: Use inttypes for printf() string
In reply to Simon GlassOn 64-bit platforms (like sandbox) 64-bit integers may be 'long' rather than 'long long'. Use the inttypes header to avoid compiler warnings.
---
fs/ext4/ext4_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/ext4/ext4_common.c +2 -1
@@ -22,6 +22,7 @@#include <common.h> #include <ext_common.h> #include <ext4fs.h> +#include <inttypes.h> #include <malloc.h> #include <stddef.h> #include <linux/stat.h>
@@ -73,7 +74,7 @@ void put_ext4(uint64_t off, void *buf, uint32_t size)if ((startblock + (size >> log2blksz)) > (part_offset + fs->total_sect)) {printf ("part_offset is " LBAFU "\n" , part_offset); -printf ("total_sector is %llu\n" , fs->total_sect); +printf ("total_sector is %" PRIu64"\n" , fs->total_sect);printf ("error: overflow occurs\n" );return ; }
Signature · 1 line
2.1.0.rc2.206.gedb03e5
PATCH 3/10 ext4: Use inttypes for printf() string
Quoted 4 lines · Simon Glass
On 64-bit platforms (like sandbox) 64-bit integers may be 'long' rather than 'long long'. Use the inttypes header to avoid compiler warnings.
Signed-off-by Simon Glass <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141027/5112ce3d/attachment.pgp>
PATCH 4/10 Use uint64_t for time types
In reply to Simon GlassUnfortunately 'unsigned long long' and 'uint64_t' are not necessarily compatible on 64-bit machines. Use the correct typedef instead of writing the supposed type out in full.
---
include/common.h | 2 +- lib/time.c | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-)
include/common.h +1 -1
@@ -776,7 +776,7 @@ void invalidate_dcache_all(void);void invalidate_icache_all (void );/* arch/$(ARCH)/lib/ticks.S */ -unsigned long long get_ticks (void ); +uint64_t get_ticks (void );void wait_ticks (unsigned long );/* arch/$(ARCH)/lib/time.c */
lib/time.c +6 -6
@@ -41,7 +41,7 @@ unsigned long notrace timer_read_counter(void)extern unsigned long __weak timer_read_counter (void );#endif -unsigned long long __weak notrace get_ticks (void ) +uint64_t __weak notrace get_ticks(void) {unsigned long now =timer_read_counter ();
@@ -49,11 +49,11 @@ unsigned long long __weak notrace get_ticks(void)if (now < gd->timebase_l) gd->timebase_h++; gd->timebase_l = now; -return ((unsigned long long )gd->timebase_h <<32 ) | gd->timebase_l; +return ((uint64_t )gd->timebase_h <<32 ) | gd->timebase_l; }/* Returns time in milliseconds */ -static unsigned long long notrace tick_to_time (unsigned long long tick) +static uint64_t notrace tick_to_time(uint64_t tick) {ulong div =get_tbclk ();
@@ -78,9 +78,9 @@ unsigned long __weak notrace timer_get_us(void)return tick_to_time (get_ticks () *1000 ); } -static unsigned long long usec_to_tick (unsigned long usec) +static uint64_t usec_to_tick (unsigned long usec) { -unsigned long long tick = usec; +uint64_t tick = usec; tick *=get_tbclk ();do_div (tick,1000000 );return tick;
@@ -88,7 +88,7 @@ static unsigned long long usec_to_tick(unsigned long usec)void __weak __udelay (unsigned long usec) { -unsigned long long tmp; +uint64_t tmp; tmp =get_ticks () +usec_to_tick (usec);/* get current timestamp */
Signature · 1 line
2.1.0.rc2.206.gedb03e5
PATCH 4/10 Use uint64_t for time types
Quoted 5 lines · Simon Glass
Unfortunately 'unsigned long long' and '
uint64_t' are not necessarily compatible on 64-bit machines. Use the correct typedef instead of writing the supposed type out in full.Signed-off-by Simon Glass <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141027/6a432bf5/attachment.pgp>
PATCH 4/10 Use uint64_t for time types
In reply to Simon GlassHi Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 3 lines
Unfortunately 'unsigned long long' and '
uint64_t' are not necessarily compatible on 64-bit machines. Use the correct typedef instead of writing the supposed type out in full.
I doubt this statement.
I think "unsigned long long" always has 64bit width.
(C specification guarantees that the width of "unsigned long long" is greater or equal to 64 bit)
Could you tell me which toolchain violates it?
Signature · 2 lines
Best Regards Masahiro Yamada
PATCH 4/10 Use uint64_t for time types
Hi Masahiro,
Quoted 8 lines · Masahiro YAMADA
Hi Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 3 lines
Unfortunately 'unsigned long long' and '
uint64_t' are not necessarily compatible on 64-bit machines. Use the correct typedef instead of writing the supposed type out in full.
Quoted 8 lines
I doubt this statement.
I think "unsigned long long" always has 64bit width.
(C specification guarantees that the width of "unsigned long long" is greater or equal to 64 bit)
Could you tell me which toolchain violates it?
Some compilers use 'unsigned long' and some use 'unsigned long long'. I think that is the core of the problem.
We don't have a problem with unsigned long long not being at least 64-bit. I wonder whether some toolchains use 128-bit for this?
Regards,
Simon
PATCH 4/10 Use uint64_t for time types
Hi Simon,
2014-12-16 3:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 18 lines
Hi Masahiro,
Quoted 15 lines · Masahiro YAMADA
Hi Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 3 lines
Unfortunately 'unsigned long long' and '
uint64_t' are not necessarily compatible on 64-bit machines. Use the correct typedef instead of writing the supposed type out in full.I doubt this statement.
I think "unsigned long long" always has 64bit width.
(C specification guarantees that the width of "unsigned long long" is greater or equal to 64 bit)
Quoted 7 lines
Quoted 1 line
Could you tell me which toolchain violates it?
Some compilers use 'unsigned long' and some use 'unsigned long long'. I think that is the core of the problem.
We don't have a problem with unsigned long long not being at least 64-bit. I wonder whether some toolchains use 128-bit for this?
That is not my point.
"unsigned long long" has 64-bit width whether on 32bit compilers or 64bit compilers or whatever.
We should always hard-code the definition:
typedef unsigned long long uint64_t;
That's all. We can always use "%llx" for printing uint64_t or u64. (and this is what U-boot (and Linux) had used until you broke the consistency.)
If we include <stdint.h>, you are right. It is the beginning of nightmare. Some compilers use "unsigned long" for uint64_t and some use "unsigned long long"
for uint64_t.
What did it buy us?
You just introduced unreadability by using PRIu64 for printing 64bit width variables.
Best Regards
Masahiro Yamada
PATCH 4/10 Use uint64_t for time types
Hi Masahiro,
Quoted 28 lines · Masahiro YAMADA
Hi Simon,
2014-12-16 3:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 23 lines
Hi Masahiro,
Quoted 8 lines · Masahiro YAMADA
Hi Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 3 lines
Unfortunately 'unsigned long long' and '
uint64_t' are not necessarily compatible on 64-bit machines. Use the correct typedef instead of writing the supposed type out in full.Quoted 8 lines
I doubt this statement.
I think "unsigned long long" always has 64bit width.
(C specification guarantees that the width of "unsigned long long" is greater or equal to 64 bit)
Could you tell me which toolchain violates it?
Some compilers use 'unsigned long' and some use 'unsigned long long'. I think that is the core of the problem.
Quoted 7 lines
Quoted 2 lines
We don't have a problem with unsigned long long not being at least 64-bit. I wonder whether some toolchains use 128-bit for this?
That is not my point.
"unsigned long long" has 64-bit width whether on 32bit compilers or 64bit compilers or whatever.
I think that might be true at least for gcc. But in principle a 64-bit machine should use 128-bit for long long.
Quoted 14 lines
We should always hard-code the definition:
typedef unsigned long longuint64_t;That's all. We can always use "%llx" for printing
uint64_tor u64. (and this is what U-boot (and Linux) had used until you broke the consistency.)If we include <
stdint.h>, you are right. It is the beginning of nightmare. Some compilers use "unsigned long" foruint64_tand some use "unsigned long long"
foruint64_t.
Quoted 4 lines
What did it buy us?
You just introduced unreadability by using PRIu64 for printing 64bit width variables.
I have also hit this problem with m68k and one other compiler in U-Boot. Is it because these compilers are broken, or something else?
Regards,
Simon
PATCH 4/10 Use uint64_t for time types
Hi Simon,
Quoted 34 lines · On Tue, 16 Dec 2014 21:38:34 -0700 Simon Glass <[email protected]> wrote:
Hi Masahiro,
Quoted 31 lines · Masahiro YAMADA
Hi Simon,
2014-12-16 3:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 25 lines
Hi Masahiro,
Quoted 8 lines · Masahiro YAMADA
Hi Simon,
2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 3 lines
Unfortunately 'unsigned long long' and '
uint64_t' are not necessarily compatible on 64-bit machines. Use the correct typedef instead of writing the supposed type out in full.Quoted 8 lines
I doubt this statement.
I think "unsigned long long" always has 64bit width.
(C specification guarantees that the width of "unsigned long long" is greater or equal to 64 bit)
Could you tell me which toolchain violates it?
Some compilers use 'unsigned long' and some use 'unsigned long long'. I think that is the core of the problem.
We don't have a problem with unsigned long long not being at least 64-bit. I wonder whether some toolchains use 128-bit for this?
Quoted 7 lines
Quoted 4 lines
That is not my point.
"unsigned long long" has 64-bit width whether on 32bit compilers or 64bit compilers or whatever.
I think that might be true at least for gcc. But in principle a 64-bit machine should use 128-bit for long long.
128-bit variable? Are you kidding?
I am not talking about "in principle" things, but talking about real compilers.
So, on which compiler do you have problems?
For instance, please?
Quoted 14 lines
Quoted 14 lines
We should always hard-code the definition:
typedef unsigned long longuint64_t;That's all. We can always use "%llx" for printing
uint64_tor u64. (and this is what U-boot (and Linux) had used until you broke the consistency.)If we include <
stdint.h>, you are right. It is the beginning of nightmare. Some compilers use "unsigned long" foruint64_tand some use "unsigned long long"
foruint64_t.
Quoted 7 lines
Quoted 4 lines
What did it buy us?
You just introduced unreadability by using PRIu64 for printing 64bit width variables.
I have also hit this problem with m68k and one other compiler in U-Boot. Is it because these compilers are broken, or something else?
I guess you are mentioning "size_t" problem on m68k.
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/188121/focus=188932
If so, you are already confused.
"size_t" is another problem that should be discussed separetely.
Notice
[1] uint32_t, int32_t, uint64_t, int64_t, uintptr_t are provided by <stdint.h>
[2] PRIx32, PRIx64, PRId32, PRId64 etc. are provided by <inttypes.h>
[3] size_t is provided by <stddef.h>
We are talking about [1] and [2].
And also notice [1] and [2] should be provided by the same compiler to work correctly.
[3] should not be mixed up with [1].
If you are interested in the topic about the conflict between "size_t" type and "%z", I can introduce you another thread.
But I am not showing that, in case this discussion goes wrong.
Best Regards
Masahiro Yamada
PATCH 5/10 Use uint64_t instead of u64 in put_dec()
In reply to Simon GlassUse the correct type required by do_div().
---
lib/vsprintf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
lib/vsprintf.c +1 -1
@@ -270,7 +270,7 @@ static char *put_dec_full(char *buf, unsigned q)return buf; }/* No inlining helps gcc to use registers better */ -static noinline char *put_dec(char *buf, u64 num) +static noinline char *put_dec(char *buf, uint64_t num) {while (1 ) {unsigned rem;
Signature · 1 line
2.1.0.rc2.206.gedb03e5
PATCH 5/10 Use uint64_t instead of u64 in put_dec()
Quoted 3 lines · Simon Glass
Use the correct type required by
do_div().Signed-off-by Simon Glass <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141027/cf400846/attachment.pgp>
PATCH 6/10 Tidy up data sizes and function comment in display_options
In reply to Simon GlassUse inttypes.h and uint64_t to correct the code so that it will not issue warnings on 64-bit machines where 'uint64_t' is 'unsigned long'.
---
include/common.h | 14 +++++++++++++- lib/display_options.c | 14 +++++--------- 2 files changed, 18 insertions(+), 10 deletions(-)
include/common.h +13 -1
@@ -256,7 +256,19 @@ int cpu_init(void);/* */ phys_size_t initdram (int );int display_options (void ); -void print_size (unsigned long long ,const char *); + +/** +* print_size() - Print a size with a suffic +* +* print sizes as "xxx KiB", "xxx.y KiB", "xxx MiB", "xxx.y MiB", +* xxx GiB, xxx.y GiB, etc as needed; allow for optional trailing string +* (like "\n") +* +* @size: Size to print +* @suffix String to print after the size +*/ +void print_size (uint64_t size,const char *suffix); +int print_buffer (ulong addr,const void *data,uint width,uint count,uint linelen);
lib/display_options.c +5 -9
@@ -7,6 +7,7 @@#include <config.h> #include <common.h> +#include <inttypes.h> #include <version.h> #include <linux/ctype.h> #include <asm/io.h>
@@ -21,15 +22,10 @@ int display_options (void)return 0 ; } -/* -* print sizes as "xxx KiB", "xxx.y KiB", "xxx MiB", "xxx.y MiB", -* xxx GiB, xxx.y GiB, etc as needed; allow for optional trailing string -* (like "\n") -*/ -void print_size (unsigned long long size,const char *s) +void print_size (uint64_t size,const char *s) {unsigned long m =0 , n; -unsigned long long f; +uint64_t f;static const char names[] = {'E' ,'P' ,'T' ,'G' ,'M' ,'K' };unsigned long d =10 *ARRAY_SIZE (names);char c =0 ;
@@ -43,7 +39,7 @@ void print_size(unsigned long long size, const char *s) }if (!c) { -printf ("%llu Bytes%s" , size, s); +printf ("%" PRIu64" Bytes%s" , size, s);return ; }
@@ -127,7 +123,7 @@ int print_buffer(ulong addr, const void *data, uint width, uint count,else x = lb.uc[i] = *(volatile uint8_t *)data;#ifdef CONFIG_SYS_SUPPORT_64BIT_DATA -printf (" %0*llx" , width *2 , x); +printf (" %0*" PRIx64, width *2 , x);#else printf (" %0*x" , width *2 , x);#endif
Signature · 1 line
2.1.0.rc2.206.gedb03e5
PATCH 6/10 Tidy up data sizes and function comment in display_options
Quoted 4 lines · Simon Glass
Use
inttypes.handuint64_tto correct the code so that it will not issue warnings on 64-bit machines where 'uint64_t' is 'unsigned long'.Signed-off-by Simon Glass <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141027/c6000e53/attachment.pgp>
PATCH 7/10 x86: Use correct printf() format string for uintptr_t
In reply to Simon GlassUse the inttypes header file to provide this.
---
arch/x86/lib/relocate.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/x86/lib/relocate.c +2 -1
@@ -16,6 +16,7 @@*/ #include <common.h> +#include <inttypes.h> #include <libfdt.h> #include <malloc.h> #include <asm/u-boot-x86.h>
@@ -94,7 +95,7 @@ int do_elf_reloc_fixups(void) *offset_ptr_ram += gd->reloc_off; }else {debug (" %p: rom reloc %x, ram %p, value %x," -" limit %lx\n" , re_src, +" limit %" PRIXPTR "\n" , re_src, re_src->r_offset, offset_ptr_ram, *offset_ptr_ram,CONFIG_SYS_TEXT_BASE + size);
Signature · 1 line
2.1.0.rc2.206.gedb03e5
PATCH 7/10 x86: Use correct printf() format string for uintptr_t
Quoted 3 lines · Simon Glass
Use the inttypes header file to provide this.
Signed-off-by Simon Glass <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141027/a55ae26c/attachment.pgp>
PATCH 8/10 scsi: Use correct printf() format string for uintptr_t
In reply to Simon GlassUse the inttypes header file to provide this.
---
common/cmd_scsi.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
common/cmd_scsi.c +5 -4
@@ -10,6 +10,7 @@*/ #include <common.h> #include <command.h> +#include <inttypes.h> #include <asm/processor.h> #include <scsi.h> #include <image.h>
@@ -391,7 +392,7 @@ static ulong scsi_read(int device, lbaint_t blknr, lbaint_t blkcnt, blks=0 ; }debug ("scsi_read_ext: startblk " LBAF -", blccnt %x buffer %lx\n" , +", blccnt %x buffer %" PRIXPTR "\n" , start, smallblks, buf_addr);if (scsi_exec (pccb) != true) {scsi_print_error (pccb);
@@ -401,7 +402,7 @@ static ulong scsi_read(int device, lbaint_t blknr, lbaint_t blkcnt, buf_addr+=pccb->datalen; }while (blks!=0 );debug ("scsi_read_ext: end startblk " LBAF -", blccnt %x buffer %lx\n" , start, smallblks, buf_addr); +", blccnt %x buffer %" PRIXPTR "\n" , start, smallblks, buf_addr);return (blkcnt); }
@@ -445,7 +446,7 @@ static ulong scsi_write(int device, lbaint_t blknr, start += blks; blks =0 ; } -debug ("%s: startblk " LBAF ", blccnt %x buffer %lx\n" , +debug ("%s: startblk " LBAF ", blccnt %x buffer %" PRIXPTR "\n" , __func__, start, smallblks, buf_addr);if (scsi_exec (pccb) != true) {scsi_print_error (pccb);
@@ -454,7 +455,7 @@ static ulong scsi_write(int device, lbaint_t blknr, } buf_addr += pccb->datalen; }while (blks !=0 ); -debug ("%s: end startblk " LBAF ", blccnt %x buffer %lx\n" , +debug ("%s: end startblk " LBAF ", blccnt %x buffer %" PRIXPTR "\n" , __func__, start, smallblks, buf_addr);return blkcnt; }
Signature · 1 line
2.1.0.rc2.206.gedb03e5
PATCH 8/10 scsi: Use correct printf() format string for uintptr_t
Quoted 3 lines · Simon Glass
Use the inttypes header file to provide this.
Signed-off-by Simon Glass <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141027/f6ee52df/attachment.pgp>
PATCH 8/10 scsi: Use correct printf() format string for uintptr_t
In reply to Simon Glass2014-10-15 19:38 GMT+09:00 Simon Glass <[email protected]>:
Quoted 21 lines
Use the inttypes header file to provide this.
Signed-off-by Simon Glass <[email protected]>---
common/cmd_scsi.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)common/cmd_scsi.c +1
-0@@ -10,6 +10,7 @@*/ #include <common.h> #include <command.h> +#include <inttypes.h> #include <asm/processor.h> #include <scsi.h> #include <image.h>
common/cmd_scsi.c static ulong scsi_read(int device, lbaint_t blknr, lbaint_t blkcnt, · line 396
Quoted 6 lines
common/cmd_scsi.c +1
-1@@ -391,7 +392,7 @@ static ulong scsi_read(int device, lbaint_t blknr, lbaint_t blkcnt, blks=0 ; }debug ("scsi_read_ext: startblk " LBAF -", blccnt %x buffer %lx\n" , +", blccnt %x buffer %" PRIXPTR "\n" , start, smallblks, buf_addr);
The root cause of the problem is to use uintptr_t provided by the compiler.
"unsigned long" can store a pointer whether it is 32bit or 64bit system. (I have never seen LLP64 on Unix-like 64bit system.)
Signature · 2 lines
Best Regards Masahiro Yamada
PATCH 9/10 usb: Use correct printf() format string for uintptr_t
In reply to Simon GlassUse the inttypes header file to provide this.
---
common/usb_storage.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
common/usb_storage.c +6 -5
@@ -33,6 +33,7 @@#include <common.h> #include <command.h> +#include <inttypes.h> #include <asm/byteorder.h> #include <asm/processor.h>
@@ -1071,7 +1072,7 @@ unsigned long usb_stor_read(int device, lbaint_t blknr, blks = blkcnt;debug ("\nusb_read: dev %d startblk " LBAF ", blccnt " LBAF -" buffer %lx\n" , device, start, blks, buf_addr); +" buffer %" PRIxPTR"\n" , device, start, blks, buf_addr); do { /* XXX need some comment here */
@@ -1101,7 +1102,7 @@ retry_it: ss->flags &= ~USB_READY ;debug ("usb_read: end startblk " LBAF -", blccnt %x buffer %lx\n" , +", blccnt %x buffer %" PRIxPTR"\n" , start, smallblks, buf_addr);usb_disable_asynch (0 );/* asynch transfer allowed */
@@ -1145,7 +1146,7 @@ unsigned long usb_stor_write(int device, lbaint_t blknr, blks = blkcnt;debug ("\nusb_write: dev %d startblk " LBAF ", blccnt " LBAF -" buffer %lx\n" , device, start, blks, buf_addr); +" buffer %" PRIxPTR"\n" , device, start, blks, buf_addr); do { /* If write fails retry for max retry count else
@@ -1176,8 +1177,8 @@ retry_it: }while (blks !=0 ); ss->flags &= ~USB_READY ; -debug ("usb_write: end startblk " LBAF ", blccnt %x buffer %lx\n" , - start, smallblks, buf_addr); +debug ("usb_write: end startblk " LBAF ", blccnt %x buffer %" + PRIxPTR"\n" , start, smallblks, buf_addr);usb_disable_asynch (0 );/* asynch transfer allowed */ if (blkcnt >=USB_MAX_XFER_BLK )
Signature · 1 line
2.1.0.rc2.206.gedb03e5
PATCH 9/10 usb: Use correct printf() format string for uintptr_t
Quoted 3 lines · Simon Glass
Use the inttypes header file to provide this.
Signed-off-by Simon Glass <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141027/35221f9f/attachment.pgp>
PATCH 10/10 test: Add a simple test to detected warnings with uint64_t, uintptr_t
In reply to Simon GlassThese types are problematic because they are typically declared in a non-standard way in U-Boot. For example, U-Boot uses 'long long' for int64_t even on a 64-bit machine whereas stdint.h uses 'long'. Similarly, U-Boot always uses 'long' for intptr_t whereas stdint.h mostly uses 'int'.
This simple test script runs a few toolchains on a few archs to check for warnings.
---
test/stdint/int-types.c | 13 ++++++++++ test/stdint/test-includes.sh | 58 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 71 insertions(+) create mode 100644 test/stdint/int-types.c create mode 100755 test/stdint/test-includes.sh
test/stdint/int-types.c new file +13 -0
@@ -0,0 +1,13 @@ +#include <common.h> +#include <inttypes.h> + +int test_types (void ) +{ +uintptr_t uintptr =0 ; +uint64_t uint64 =0 ; +u64 u64_val =0 ; + +printf ("uintptr = %" PRIuPTR"\n" , uintptr); +printf ("uint64 = %" PRIu64"\n" , uint64); +printf ("u64 = %" PRIu64"\n" , u64_val); +}
test/stdint/test-includes.sh new file +58 -0
58 lines not on this page · raw message
Signature · 1 line
2.1.0.rc2.206.gedb03e5
PATCH 10/10 test: Add a simple test to detected warnings with uint64_t, uintptr_t
Quoted 10 lines · Simon Glass
These types are problematic because they are typically declared in a non-standard way in U-Boot. For example, U-Boot uses 'long long' for
int64_teven on a 64-bit machine whereasstdint.huses 'long'. Similarly, U-Boot always uses 'long' forintptr_twhereasstdint.hmostly uses 'int'.This simple test script runs a few toolchains on a few archs to check for warnings.
Signed-off-by Simon Glass <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141027/7745c5c2/attachment.pgp>
cover Provide inttypes.h to avoid 32/64 bit problems with printf()
In reply to Simon Glass+Jeroen
Hi,
Quoted 18 lines · Simon Glass
In quite a few situations we have to print a 64-bit value. Unfortunately the type used for 64-bit can vary depending on the machine. For 64-bit machines it might be 'long' and for 32-bit machines it might be 'long long'.
As a result we need to use either %ld or %lld depending on the architecture. Add the
inttypes.hheader file to provide defines for this and clean up the code to use these defines in a few places.The
stdint.hfile is bundled with recent versions of gcc and it is generally better to use this rather than our own versions. Add an option to use the internalstdint.hfile.Gabe Black (2):
Provide option to avoid defining a custom version ofuintptr_t. Add some standard headers external code might need
Quoted 9 lines
Simon Glass (8):
ext4: Use inttypes forprintf()string
Useuint64_tfor time types
Useuint64_tinstead of u64 input_dec()
Tidy up data sizes and function comment indisplay_options
x86: Use correctprintf()format string foruintptr_t
scsi: Use correctprintf()format string foruintptr_t
usb: Use correctprintf()format string foruintptr_t
test: Add a simple test to detected warnings withuint64_t,uintptr_t
Are there any comments on this series? I'm keen to clean up the printf() types a bit. Also this simplifies building withe external libraries, and with more work might reduce the difference between U-Boot code in /tools and the rest of it.
Quoted 25 lines
README | 5 + arch/sandbox/include/asm/types.h | 5 + arch/x86/include/asm/types.h | 5 + arch/x86/lib/relocate.c | 3 +- common/cmd_scsi.c | 9 +- common/usb_storage.c | 11 +- config.mk | 5 + fs/ext4/ext4_common.c | 3 +- include/common.h | 19 ++- include/compiler.h | 11 +- include/inttypes.h | 287 +++++++++++++++++++++++++++++++++++++++ include/linux/types.h | 9 +- include/stdlib.h | 12 ++ lib/display_options.c | 14 +- lib/time.c | 12 +- lib/vsprintf.c | 2 +- test/stdint/int-types.c | 13 ++ test/stdint/test-includes.sh | 58 ++++++++ 18 files changed, 450 insertions(+), 33 deletions(-) create mode 100644 include/inttypes.h create mode 100644 include/stdlib.h create mode 100644 test/stdint/int-types.c create mode 100755 test/stdint/test-includes.sh
Quoted 3 lines
--
2.1.0.rc2.206.gedb03e5
Regards,
Simon
cover Provide inttypes.h to avoid 32/64 bit problems with printf()
Hello Simon,
Quoted 32 lines · Simon Glass
+Jeroen
Hi,
Quoted 18 lines · Simon Glass
In quite a few situations we have to print a 64-bit value. Unfortunately the type used for 64-bit can vary depending on the machine. For 64-bit machines it might be 'long' and for 32-bit machines it might be 'long long'.
As a result we need to use either %ld or %lld depending on the architecture. Add the
inttypes.hheader file to provide defines for this and clean up the code to use these defines in a few places.The
stdint.hfile is bundled with recent versions of gcc and it is generally better to use this rather than our own versions. Add an option to use the internalstdint.hfile.Gabe Black (2):
Provide option to avoid defining a custom version ofuintptr_t. Add some standard headers external code might needQuoted 9 lines
Simon Glass (8):
ext4: Use inttypes forprintf()string
Useuint64_tfor time types
Useuint64_tinstead of u64 input_dec()
Tidy up data sizes and function comment indisplay_options
x86: Use correctprintf()format string foruintptr_t
scsi: Use correctprintf()format string foruintptr_t
usb: Use correctprintf()format string foruintptr_t
test: Add a simple test to detected warnings withuint64_t,uintptr_t
Quoted 4 lines
Are there any comments on this series? I'm keen to clean up the
printf()types a bit. Also this simplifies building withe external libraries, and with more work might reduce the difference between U-Boot code in /tools and the rest of it.
No comments from my side. clang seem to digest this fine.
Regards,
Jeroen
cover Provide inttypes.h to avoid 32/64 bit problems with printf()
In reply to Simon GlassHi Simon, attempt two..
Quoted 32 lines · Simon Glass
+Jeroen
Hi,
Quoted 18 lines · Simon Glass
In quite a few situations we have to print a 64-bit value. Unfortunately the type used for 64-bit can vary depending on the machine. For 64-bit machines it might be 'long' and for 32-bit machines it might be 'long long'.
As a result we need to use either %ld or %lld depending on the architecture. Add the
inttypes.hheader file to provide defines for this and clean up the code to use these defines in a few places.The
stdint.hfile is bundled with recent versions of gcc and it is generally better to use this rather than our own versions. Add an option to use the internalstdint.hfile.Gabe Black (2):
Provide option to avoid defining a custom version ofuintptr_t. Add some standard headers external code might needQuoted 9 lines
Simon Glass (8):
ext4: Use inttypes forprintf()string
Useuint64_tfor time types
Useuint64_tinstead of u64 input_dec()
Tidy up data sizes and function comment indisplay_options
x86: Use correctprintf()format string foruintptr_t
scsi: Use correctprintf()format string foruintptr_t
usb: Use correctprintf()format string foruintptr_t
test: Add a simple test to detected warnings withuint64_t,uintptr_t
Quoted 4 lines
Are there any comments on this series? I'm keen to clean up the
printf()types a bit. Also this simplifies building withe external libraries, and with more work might reduce the difference between U-Boot code in /tools and the rest of it.
No comments from my side. clang seem to digest this fine.
Regards,
Jeroen
cover Provide inttypes.h to avoid 32/64 bit problems with printf()
Hi Jeroen,
Quoted 41 lines · Jeroen Hofstee
Hi Simon, attempt two..
Quoted 38 lines · Simon Glass
+Jeroen
Hi,
Quoted 31 lines · Simon Glass
In quite a few situations we have to print a 64-bit value. Unfortunately the type used for 64-bit can vary depending on the machine. For 64-bit machines it might be 'long' and for 32-bit machines it might be 'long long'.
As a result we need to use either %ld or %lld depending on the architecture.
Add theinttypes.hheader file to provide defines for this and clean up the
code to use these defines in a few places.The
stdint.hfile is bundled with recent versions of gcc and it is generally
better to use this rather than our own versions. Add an option to use the internalstdint.hfile.Gabe Black (2):
Provide option to avoid defining a custom version ofuintptr_t. Add some standard headers external code might needSimon Glass (8):
ext4: Use inttypes forprintf()string
Useuint64_tfor time types
Useuint64_tinstead of u64 input_dec()
Tidy up data sizes and function comment indisplay_options
x86: Use correctprintf()format string foruintptr_t
scsi: Use correctprintf()format string foruintptr_t
usb: Use correctprintf()format string foruintptr_t
test: Add a simple test to detected warnings withuint64_t,uintptr_t
Quoted 7 lines
Quoted 4 lines
Are there any comments on this series? I'm keen to clean up the
printf()types a bit. Also this simplifies building withe external libraries, and with more work might reduce the difference between U-Boot code in /tools and the rest of it.No comments from my side. clang seem to digest this fine.
OK that's good. Thanks for trying it out.
Regards,
Simon