[PATCH] Add basic m68k support to crosstool-ng

Remy Bohmer linux@bohmer.net
Sun Feb 7 11:52:00 GMT 2010

Hi Yann,

2010/1/28 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>:
> Hello Remy, All!
> Whaoo! Very nice! Thank you for the submission! :-)
> I have however a few questions, see below...
> On Thursday 28 January 2010 19:57:14 Remy Bohmer wrote:
>> +config ARCH_m68k
>> +    select ARCH_SUPPORTS_32
>> +    select ARCH_DEFAULT_32
>> +    select ARCH_DEFAULT_BE
>> +    select ARCH_SUPPORT_CPU
> From the gcc man page, it seems you can also pass -march and -mtune.
> Did you exclude those on purpose, or is it a oversight?

I excluded them because they were not yet needed.

> [--SNIP--]
>> +#
>> +# Operating System
>> +#
>> +CT_KERNEL="bare-metal"
>> +CT_KERNEL_bare_metal=y
>> +# CT_KERNEL_linux is not set
> This means a bare-metal target. OK.
> Is it possible to generate:
> - m68k-linux-gnu ?
> - m68k-linux-uclibc ?

Maybe, but I did not look into that.
We only need a bare metal compiler to replace another old exotic
compiler, running linux on an ancient 20MHz processor  with just 512kB
of RAM is not that useful...

>> +#
>> +# elf2flt
>> +#
>> +# CT_ELF2FLT_CVS_SNAPSHOT is not set
> elf2flt is currently disabled in the code. We do not (yet) build it, as
> we do not call its functions (for now).

elf2flt was auto-magically selected, I did not select it on purpose.
Actually we even do not need the elf2flt code.
We will create a separate patch to get rid of this unexpected and
unwanted relation.

> Did you notice that?
> Was your toolchain functional?

We are still testing it, but everything looks good, and the compiler
seems to deliver proper executables.
However, we have not yet build a complete product with it so there
might still be some issues, but we will fix those as well.

> [--SNIP--]
>> +CT_DoArchTupleValues() {
>> +    # The architecture part of the tuple:
> This is the default, and needs not be repeated.

Copy-pasted from another architecture... (x86_64)

> This is a whole new architecture, and should not disrupt existing code,
> so I'll add it. I'd like to read your answers, however, at least for my
> own curiosity, or better yet, so we can improve m68k support.

Soon, there will be updates to this architecture to make it more
useful. (Me or Bart will post those)
We also want a canadian build for this toolchain (Windows hosted) and
we are having some issues to get it compiled properly.
We also want newlib support in it as well. (does not compile yet)

Kind regards,


For unsubscribe information see http://sourceware.org/lists.html#faq

More information about the crossgcc mailing list