Dear Masahiro,
On 15/12/2014 17:46, Masahiro YAMADA wrote:
This is a known (and unfortunate) problem.
The Linux m68k toolchains (as I am using) define size_t as "unsigned int", whereas bare-metal m68k toolchains (as you are using) define size_t as "unsigned long".
People often want to adjust the type definition to the toolchains they are using.
Commit ddc94378d changed __kernel_size_t definition from "unsigned int" to "unsigned long".
Commit fbe79a17 changed it back to "unsigned int" again.
BTW, Linux Kernel has the same problem as we have for U-Boot.
I posted a question about this to LKML.
If you are interested in it, check out this thread: https://lkml.org/lkml/2014/12/15/110
According to that thread, the solution the kernel folks chose is to always use toolchains configured for Linux.
For U-Boot, I think we have two options
[1] Follow the Linux's way: Ban bare-metal toolchains and always use kernel.org ones
[2] Use __SIZE_TYPE__ (or include <stddef.h>) to support both types of toolchains.
Many thanks for the deep analysis and clarifications.
For me, it is good we know [1] is compiling properly, so i am fine to adopt the kernel.org 32/64 bit toolchains for m68k development, if the community agree, i can prepare a u.boot m68k wiki page with this information.
The discussion for [2] is interesting to me, i am trying to understand the thing properly but i still have some doubts: from my understanding, a bare-metal toolchain should be without libc support (or minimal), so the kernel.org "nolibc" should be considered bare-metal ? If so, could the issue be related to "certain" toolchain only ?
Also, i am not understanding, i am comparing now 2 different toolchains:
CROSS_COMPILE=/opt/toolchains/Sourcery_CodeBench_Lite_for_ColdFire_ELF/bin/m68k-elf- /MAKEALL -a m68k compiles with warning: format '%zx' expects argument of type 'size_t', but argument 4 has type 'unsigned int' [-Wformat]
CROSS_COMPILE=/opt/toolchains/Sourcery_CodeBench_Lite_for_ColdFire_uClinux/bin/m68k-uclinux- ./MAKEALL -a m68k this compiles fine, no warnings
But if i look to the <stddef.h> of the 2 toolchains, they are exactly the same. So why the compilers expects different definitions of size_t ?
Regards, Angelo Dureghello
Option [2] would be better of course, could the change to use __SIZE_TYPE__ (or include <stddef.h>) be done in a single place ? What impact it can have for other architectures then ?
We can also simply collect in a wiki page for m68k dev this informations, (to use kernel.org, and explain the warning reason).
Best Regards Angelo Dureghello
Best Regards Masahiro Yamada