[U-Boot] [OpenQuestion] stdint.h and inttypes.h in U-Boot ?
Simon Glass
sjg at chromium.org
Fri Nov 28 05:27:54 CET 2014
Hi Masahiro,
On 27 Nov 2014 19:22, "Masahiro Yamada" <yamada.m at jp.panasonic.com> wrote:
>
>
> No comments on this topic?
> Nobody cares even if I revert commit 0d296cc and 4166ecb ?
>
>
I do, but need to go back to my original patch and come up with a response.
Also it is holidays here.
Regards,
Simon
>
>
>
> 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
>
>
More information about the U-Boot
mailing list