Hi Simon,
On Mon, 22 Dec 2014 21:41:48 -0700 Simon Glass <[email protected]> wrote: > Hi Masahiro, > > On 22 December 2014 at 03:15, Masahiro Yamada <[email protected]> > wrote: > > The intent of this series is to show the nasty problems introduced > > by <stdint.h>. > > > > Simon and I are already discussing this in the following thread: > > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/203954 > > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/198550/focus=205880 > > I'll reply on that thread but I will add a few comments on each patch as well. > > > > > ----- > > > > Commit 0d296cc2d3b8 (Provide option to avoid defining a custom version > > of uintptr_t.) introduced CONFIG_USE_STDINT. If it is enabled, > > <stdint.h> is included and uint64_t, u_int64_t, int64_t are defined > > based on the compiler-provided information. While, inconsistently, > > that commit left uint_{8,16,32}_t, u_int{8,16,32}t, int_{8,16,32}t > > to be hard-coded in include/linux/types.h. > > > > This causes type conflicts between the typedefs defined in the compiler's > > <stdint.h> and the ones hard-coded in include/linux/types.h. > > > > As you may know, 'uint32_t' is defined as 'unsigned long' in some compilers > > such as bare metal ARM toolchain, whereas it is defined as 'unsigned int' > > in kernel.org ones. > > (This is also clearly mentioned in Linux's arch/arm/include/asm/types.h) > > In that file, it actually redefines the types so that stdint.h can be > included. Are you suggesting that we should follow the same route? No. What I wanted you to notice was the type conflicts. This matrix: * 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 Undefing __UINT32_TYPE__ etc. is an ugly workaround. The best way is to avoid including <stdint.h>. > That suggests that Gabe's implementation is not correct, but not that > the whole concept is wrong. > > * 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). Accoding to Documentation/arm/kernel_mode_neon.txt, the kernel deos not want to include <stdint.h>. It wants to <arm_neon.h> but unfortunately <arm_neon.h> is including <stdint.h>. That is the difference: it looks like you like to include <stdint.h>. > > > > If you make a decision to use a compiler-provided <stdint.h>, > > we cannot hard-code the fixed-width types. > > To avoid the type conflicts, we must make all of them compiler-dependent > > consistently. > > > > You can reproduce this problem, for example, with a Linaro toolchain. > > > > Visit "http://www.linaro.org/downloads/"; and download "Bare-metal toolchain > > for Cortex-R/M and Cortex-A". > > > > $ make USE_STDINT=1 CROSS_COMPILE=arm-none-eabi- omap4_panda_defconfig all > > HOSTCC scripts/basic/fixdep > > HOSTCC scripts/kconfig/conf.o > > [snip] > > CC lib/asm-offsets.s > > In file included from > > /opt/gcc-arm-none-eabi-4_7-2013q1/bin/../lib/gcc/arm-none-eabi/4.7.3/include/stdint.h:5:0, > > from include/compiler.h:117, > > from include/image.h:19, > > from include/common.h:82, > > from lib/asm-offsets.c:15: > > /opt/gcc-arm-none-eabi-4_7-2013q1/bin/../lib/gcc/arm-none-eabi/4.7.3/include/stdint-gcc.h:40:24: > > error: conflicting types for 'int32_t' > > In file included from include/common.h:21:0, > > from lib/asm-offsets.c:15: > > include/linux/types.h:99:17: note: previous declaration of 'int32_t' was > > here > > In file included from > > /opt/gcc-arm-none-eabi-4_7-2013q1/bin/../lib/gcc/arm-none-eabi/4.7.3/include/stdint.h:5:0, > > from include/compiler.h:117, > > from include/image.h:19, > > from include/common.h:82, > > from lib/asm-offsets.c:15: > > /opt/gcc-arm-none-eabi-4_7-2013q1/bin/../lib/gcc/arm-none-eabi/4.7.3/include/stdint-gcc.h:52:25: > > error: conflicting types for 'uint32_t' > > In file included from include/common.h:21:0, > > from lib/asm-offsets.c:15: > > include/linux/types.h:105:17: note: previous declaration of 'uint32_t' was > > here > > I suspect I have not tested this toolchain, so have not see this > problem. Perhaps this compiler cannot support stdint.h? It does support stdint.h. It is not the compiler's fault, but your and Gabe's fault. > In any case I don't think it is necessary to fiddle with the 8, 16, > 32-bit types, so this patch is not needed. > As I wrote in another reply, please answer: Why do you want to change the 64bit-types only? Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
