Hi Masahiro, On 27 Nov 2014 19:22, "Masahiro Yamada" <[email protected]> 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 <[email protected]> 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@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 > > [email protected] > > http://lists.denx.de/mailman/listinfo/u-boot > >
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
