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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
