public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Angelo Dureghello <angelo@sysam.it>
To: u-boot@lists.denx.de
Subject: [U-Boot] m68k: Build problems on some boards
Date: Mon, 22 Dec 2014 19:06:51 +0100	[thread overview]
Message-ID: <54985DBB.20409@sysam.it> (raw)
In-Reply-To: <CAMhH57Sjp08f3MQjwEeBTNYCxKwQKS8=TcFxuafLoYqVzaorUw@mail.gmail.com>

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

  reply	other threads:[~2014-12-22 18:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-01 20:41 [U-Boot] m68k: Build problems on some boards Angelo Dureghello
2014-12-01 23:17 ` Angelo Dureghello
2014-12-02  4:26 ` Masahiro Yamada
2014-12-02  9:22   ` Angelo Dureghello
2014-12-15 16:46     ` Masahiro YAMADA
2014-12-22 18:06       ` Angelo Dureghello [this message]
2015-01-26 20:54       ` Angelo Dureghello
  -- strict thread matches above, loose matches on Subject: below --
2014-06-15 12:57 Vasili Galka
2014-06-22  9:19 ` Vasili Galka
2014-06-23 13:10   ` Tom Rini
2014-07-22  3:38     ` Masahiro Yamada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54985DBB.20409@sysam.it \
    --to=angelo@sysam.it \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox