[U-Boot] [OpenQuestion] stdint.h and inttypes.h in U-Boot ?

[Masahiro Yamada]

No comments on this topic?
Nobody cares even if I revert commit 0d296cc and 4166ecb ?





On Wed, 26 Nov 2014 16:45:51 +0900
Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:

> Hi Tom, Simon, other developers,
> 
> 
> 
> Since commit 0d296cc2d3b8 (Provide option to avoid defining a custom version of uintptr_t)
> and commit 4166ecb247a1 (Add some standard headers external code might need),
> I have been wondering if they were right decisions.
> 
> 
> 
> As arch/arm/include/asm/types.h of Linux Kernel says,
> using 'stdint.h' is not feasible.
> 
> -------------------------------------->8-------------------------------------
> /*
>  * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
>  * unambiguous on ARM as you would expect. For the types below, there is a
>  * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
>  * and the kernel itself, which results in build errors if you try to build with
>  * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
>  * in order to use NEON intrinsics)
>  *
>  * As the typedefs for these types in 'stdint.h' are based on builtin defines
>  * supplied by GCC, we can tweak these to align with the kernel's idea of those
>  * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
>  * source file (provided that -ffreestanding is used).
>  *
>  *                    int32_t         uint32_t               uintptr_t
>  * bare metal GCC     long            unsigned long          unsigned int
>  * glibc GCC          int             unsigned int           unsigned int
>  * kernel             int             unsigned int           unsigned long
>  */
> --------------------------------------8<----------------------------------------
> 
> 
> Actually, the kernel never includes <stdint.h> except host programs.
> 
> 
> Commit 0d296cc2d3b8 introduced "USE_STDINT", but it causes type conflicts
> depending on which GCC is used.
> 
> 
> With ARM bare metal GCC,
> 
> yamada at beagle:~/workspace/u-boot$ make omap3_beagle_defconfig all CROSS_COMPILE=arm-none-eabi- USE_STDINT=1
> #
> # configuration written to .config
> #
> #
> # configuration written to spl/.config
> #
> scripts/kconfig/conf --silentoldconfig Kconfig
> scripts/kconfig/conf --silentoldconfig Kconfig
>   CHK     include/config.h
>   GEN     include/autoconf.mk
>   GEN     include/autoconf.mk.dep
>   GEN     spl/include/autoconf.mk
>   CHK     include/config/uboot.release
>   CHK     include/generated/version_autogenerated.h
>   CHK     include/generated/timestamp_autogenerated.h
>   UPD     include/generated/timestamp_autogenerated.h
>   CC      lib/asm-offsets.s
> In file included from /opt/arm-2011.03/bin/../lib/gcc/arm-none-eabi/4.5.2/include/stdint.h:5:0,
>                  from include/compiler.h:117,
>                  from include/image.h:19,
>                  from include/common.h:85,
>                  from lib/asm-offsets.c:15:
> /opt/arm-2011.03/bin/../lib/gcc/arm-none-eabi/4.5.2/include/stdint-gcc.h:40:24: error: conflicting types for 'int32_t'
> include/linux/types.h:99:17: note: previous declaration of 'int32_t' was here
> /opt/arm-2011.03/bin/../lib/gcc/arm-none-eabi/4.5.2/include/stdint-gcc.h:52:25: error: conflicting types for 'uint32_t'
> include/linux/types.h:105:17: note: previous declaration of 'uint32_t' was here
> make[2]: *** [lib/asm-offsets.s] Error 1
> make[1]: *** [prepare0] Error 2
> make: *** [__build_one_by_one] Error 2
> 
> 
> 
> 
> OK, we can fix "int32_t" and "uint32_t", but it still seems strange to see that
>  "uint32_t" is defined as "unsigned long", whereas "u32" is defined as "unsigned int".
> 
> If so, must we fix "u32", "s32", ... all the fixed-width typedefs ?
> 
> I notice including <linux/types.h> in the U-Boot source tree and
> <stdint.h> provided by your compiler at the same time is a nightmare.
> 
> If we lean toward <stdint.h>, we must ban <linux/types.h>,
> but <stdint.h> is not available all the time.
> For example, kernel.org tool-chains do not provide <stdint.h>.
> 
> Maybe we can drastically re-write <linux/types.h> and friends
> to resolve the type conflicts, but I do not think we should not drift apart from the kernel
> because we have borrowed many source files from Linux.
> 
> 
> 
> 
> Best Regards
> Masahiro Yamada
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot