[uClinux-dev] Latest GCC toolchain for m68k

Post by Luis Alves
I'm currently using the 'experimental' pre-built gcc toolchain from
<http://www.uclinux.org/pub/uClinux/arm-elf-tools/tools-20080626/m68k-uclinux-tools-20080626.sh>
to build my uClinux-dist.
I've never found any issue with that package, so I didn't even bother
to build my own toolchain.
But now I'm wondering: Is there a newer/better pre-built toolchain, or
sorces for building a more recent one.

I built my own. Pretty sure I told the list what I used back when I
did it. I currently have gcc 4.3.3, binutils 2.19.1, elf2flt checkout
from blackfin on 2009-04-20, kernel 2.6.29.1 (the fec changes in 2.6.30
mean doing some patch rework that we haven't gotten around to doing), and
uclibc from git that is pretty much 0.9.31 (it's slightly before that).

Everything built from upstream sources.

--
Len Sorensen

Ezequiel Garcia

2012-05-14 22:12:04 UTC

On Mon, May 14, 2012 at 1:26 PM, Lennart Sorensen

I built my own. ?Pretty sure I told the list what I used back when I
did it. ?I currently have gcc 4.3.3, binutils 2.19.1, elf2flt checkout
from blackfin on 2009-04-20, kernel 2.6.29.1 (the fec changes in 2.6.30
mean doing some patch rework that we haven't gotten around to doing), and
uclibc from git that is pretty much 0.9.31 (it's slightly before that).
Everything built from upstream sources.

Do you have any scripts or something to share with us?

I tried to build one using gentoo crossdev, but couldn't get the
elf2flt stuff correctly (and didn't have much time to fix it).

Ivica Eftimovski

2012-05-14 16:54:40 UTC

Hi Luis,

I use CodeSourcery/Mentor Graphics prebuilt toolset. I have build my own for the m68k before, but personally I advise you against it, especially on Windows/Cygwin. CodeSourcery has a "Lite" free version of the toolchain for m68k uClinux running both on Windows and Linux at http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/ .

Ivica

-----Original Message-----
From: uclinux-dev-bounces at uclinux.org [mailto:uclinux-dev-bounces at uclinux.org] On Behalf Of Luis Alves
Sent: Monday, May 14, 2012 11:08 AM
To: uClinux development list
Subject: [uClinux-dev] Latest GCC toolchain for m68k

Hi,

I'm currently using the 'experimental' pre-built gcc toolchain from <http://www.uclinux.org/pub/uClinux/arm-elf-tools/tools-20080626/m68k-uclinux-tools-20080626.sh>
to build my uClinux-dist.

I've never found any issue with that package, so I didn't even bother to build my own toolchain.

But now I'm wondering: Is there a newer/better pre-built toolchain, or sorces for building a more recent one.

Thanks,
Luis
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Greg Ungerer

2012-05-15 05:00:36 UTC

Hi Luis,

That tools page on uclinux.org is looking kind of crufty.

I am uploading the latest one I generated and use now, 20101118.
It is based around gcc-4.5.1. I have been using it for quite a while
and have no problems with it.

As Ivica suggests the code sourcery ones are a good choice too.

Or if you feel up to it take the build script in with the 20101118
sources and try building your own. It is character building :-)

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com

Luis Alves

2012-05-15 11:53:24 UTC

Hi Greg,

I've tryed using the toolchain that you just uploaded but is failing
complaining that some shared libraries are missing:

[...]
/usr/local/libexec/gcc/m68k-uclinux/4.5.1/cc1: error while loading
shared libraries: libmpfr.so.1: cannot open shared object file: No
such file or directory

And ldd shows:

# ldd /usr/local/libexec/gcc/m68k-uclinux/4.5.1/cc1
linux-gate.so.1 => (0xb7742000)
libmpc.so.2 => /usr/lib/libmpc.so.2 (0xb7719000)
libmpfr.so.1 => not found
libgmp.so.3 => not found
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7713000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb76fe000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7580000)
libmpfr.so.4 => /usr/lib/libmpfr.so.4 (0xb7529000)
libgmp.so.10 => /usr/lib/libgmp.so.10 (0xb74b2000)
/lib/ld-linux.so.2 (0xb7743000)

What's the linux distro this has been compiled in (and arch)?

Anyway, I guess I'll compile my own toolchain.

Regards,
Luis

Post by Ivica Eftimovski
Hi Luis,

That tools page on uclinux.org is looking kind of crufty.
I am uploading the latest one I generated and use now, 20101118.
It is based around gcc-4.5.1. I have been using it for quite a while
and have no problems with it.
As Ivica suggests the code sourcery ones are a good choice too.
Or if you feel up to it take the build script in with the 20101118
sources and try building your own. It is character building :-)
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer ?-- ?Principal Engineer ? ? ? ?EMAIL: ? ? gerg at snapgear.com
SnapGear Group, McAfee ? ? ? ? ? ? ? ? ? ? ?PHONE: ? ? ? +61 7 3435 2888
8 Gardner Close ? ? ? ? ? ? ? ? ? ? ? ? ? ? FAX: ? ? ? ? +61 7 3217 5323
Milton, QLD, 4064, Australia ? ? ? ? ? ? ? ?WEB: http://www.SnapGear.com

Greg Ungerer

2012-05-15 12:32:26 UTC

Hi Luis,

Post by Luis Alves
I've tryed using the toolchain that you just uploaded but is failing
[...]
/usr/local/libexec/gcc/m68k-uclinux/4.5.1/cc1: error while loading
shared libraries: libmpfr.so.1: cannot open shared object file: No
such file or directory
# ldd /usr/local/libexec/gcc/m68k-uclinux/4.5.1/cc1
linux-gate.so.1 => (0xb7742000)
libmpc.so.2 => /usr/lib/libmpc.so.2 (0xb7719000)
libmpfr.so.1 => not found
libgmp.so.3 => not found
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7713000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb76fe000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7580000)
libmpfr.so.4 => /usr/lib/libmpfr.so.4 (0xb7529000)
libgmp.so.10 => /usr/lib/libgmp.so.10 (0xb74b2000)
/lib/ld-linux.so.2 (0xb7743000)
What's the linux distro this has been compiled in (and arch)?

I compiled it on a Ubuntu 10.4 (I think it was 10.4). I had to install
a few extra libs packages, like libmpfr and libgmp. They are an easy
apt-get install on ubuntu.

Regards
Greg

Post by Luis Alves
Anyway, I guess I'll compile my own toolchain.
Regards,
Luis

Post by Ivica Eftimovski
Hi Luis,

That tools page on uclinux.org is looking kind of crufty.
I am uploading the latest one I generated and use now, 20101118.
It is based around gcc-4.5.1. I have been using it for quite a while
and have no problems with it.
As Ivica suggests the code sourcery ones are a good choice too.
Or if you feel up to it take the build script in with the 20101118
sources and try building your own. It is character building :-)
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer ??-- ??Principal Engineer ?? ?? ?? ??EMAIL: ?? ?? gerg at snapgear.com
SnapGear Group, McAfee ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??PHONE: ?? ?? ?? +61 7 3435 2888
8 Gardner Close ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? FAX: ?? ?? ?? ?? +61 7 3217 5323
Milton, QLD, 4064, Australia ?? ?? ?? ?? ?? ?? ?? ??WEB: http://www.SnapGear.com

--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close, FAX: +61 7 3891 3630
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com

Luis Alves

2012-05-16 09:12:58 UTC

Hi Greg,

I've solved the missing libraries problem but the toolchain you
provided isn't generating proper code for the 68000.

I've disassembled the kernel and checked the 'proc_net_ns_init'
function, where the kernel is hanging more precisely at the 'memcpy'
intruction.

So, the memcpy gets compiled into a movel instruction with an odd
displacement (causing a bus error).

memcpy(netd->name, "net", 4);

compiled into:

[...]
2175b8: 217c 6e65 7400 movel #1852142592,%a0@(77)
2175be: 004d
[...]

The previous toolchain is generating 4 moveb intructions in this case.
I also see some other differences related to move opcodes.

For instance, the previous toolchain loads an address content to the
stack by doing this:

207104: 2f39 001f 54c8 movel 1f54c8 <malloc_sizes+0x1c>,%sp at -
20710a: 4eb9 0004 2bbc jsr 42bbc <kmem_cache_alloc>

The new toolchain is doing this:

21755a: 307c 001c moveaw #28,%a0
21755e: d1fc 0020 6d2c addal #2125100,%a0
217564: 2f10 movel %a0@,%sp at -
217566: 4eb9 0004 640e jsr 4640e <kmem_cache_alloc>

To me this looks Coldfire 'limited' adressing modes.

Any suggestion? :|

When ever i have the time I'll try to build a toolchain (maybe using
gcc 4.7) and check the generated code.
Maybe I also could try the code sourcery one, but there is no
reference for the 'legacy 68k' family on their download page (only
coldfire).

Regards,
Luis Alves

Hi Luis,

Post by Luis Alves
I've tryed using the toolchain that you just uploaded but is failing
[...]
/usr/local/libexec/gcc/m68k-uclinux/4.5.1/cc1: error while loading
shared libraries: libmpfr.so.1: cannot open shared object file: No
such file or directory
# ldd /usr/local/libexec/gcc/m68k-uclinux/4.5.1/cc1
? ? ? ?linux-gate.so.1 => ? (0xb7742000)
? ? ? ?libmpc.so.2 => ?/usr/lib/libmpc.so.2 (0xb7719000)
? ? ? ?libmpfr.so.1 => ?not found
? ? ? ?libgmp.so.3 => ?not found
? ? ? ?libdl.so.2 => ?/lib/i386-linux-gnu/libdl.so.2 (0xb7713000)
? ? ? ?libz.so.1 => ?/lib/i386-linux-gnu/libz.so.1 (0xb76fe000)
? ? ? ?libc.so.6 => ?/lib/i386-linux-gnu/libc.so.6 (0xb7580000)
? ? ? ?libmpfr.so.4 => ?/usr/lib/libmpfr.so.4 (0xb7529000)
? ? ? ?libgmp.so.10 => ?/usr/lib/libgmp.so.10 (0xb74b2000)
? ? ? ?/lib/ld-linux.so.2 (0xb7743000)
What's the linux distro this has been compiled in (and arch)?

I compiled it on a Ubuntu 10.4 (I think it was 10.4). I had to install
a few extra libs packages, like libmpfr and libgmp. They are an easy
apt-get install on ubuntu.
Regards
Greg

Post by Luis Alves
Anyway, I guess I'll compile my own toolchain.
Regards,
Luis

Post by Ivica Eftimovski
Hi Luis,

That tools page on uclinux.org is looking kind of crufty.
I am uploading the latest one I generated and use now, 20101118.
It is based around gcc-4.5.1. I have been using it for quite a while
and have no problems with it.
As Ivica suggests the code sourcery ones are a good choice too.
Or if you feel up to it take the build script in with the 20101118
sources and try building your own. It is character building :-)
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer ??-- ??Principal Engineer ?? ?? ?? ??EMAIL: ?? ?? gerg at snapgear.com
SnapGear Group, McAfee ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??PHONE: ?? ?? ?? +61 7 3435 2888
8 Gardner Close ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? FAX: ?? ?? ??
?? +61 7 3217 5323
http://www.SnapGear.com

--
------------------------------------------------------------------------
Greg Ungerer ?-- ?Principal Engineer ? ? ? ?EMAIL: ? ? gerg at snapgear.com
SnapGear Group, McAfee ? ? ? ? ? ? ? ? ? ? ?PHONE: ? ? ? +61 7 3435 2888
8 Gardner Close, ? ? ? ? ? ? ? ? ? ? ? ? ? ?FAX: ? ? ? ? +61 7 3891 3630
Milton, QLD, 4064, Australia ? ? ? ? ? ? ? ?WEB: http://www.SnapGear.com

Greg Ungerer

2012-05-16 11:44:08 UTC

Hi Luis,

Post by Luis Alves
I've solved the missing libraries problem but the toolchain you
provided isn't generating proper code for the 68000.
I've disassembled the kernel and checked the 'proc_net_ns_init'
function, where the kernel is hanging more precisely at the 'memcpy'
intruction.
So, the memcpy gets compiled into a movel instruction with an odd
displacement (causing a bus error).

memcpy(netd->name, "net", 4);

[...]
2175be: 004d
[...]
The previous toolchain is generating 4 moveb intructions in this case.
I also see some other differences related to move opcodes.
For instance, the previous toolchain loads an address content to the
207104: 2f39 001f 54c8 movel 1f54c8<malloc_sizes+0x1c>,%sp at -
20710a: 4eb9 0004 2bbc jsr 42bbc<kmem_cache_alloc>
21755a: 307c 001c moveaw #28,%a0
21755e: d1fc 0020 6d2c addal #2125100,%a0
217566: 4eb9 0004 640e jsr 4640e<kmem_cache_alloc>
To me this looks Coldfire 'limited' adressing modes.
Any suggestion? :|

What are the compiler options supplied to gcc?
(If you make the kernel with V=1 then you get the full command
line trace)

Post by Luis Alves
When ever i have the time I'll try to build a toolchain (maybe using
gcc 4.7) and check the generated code.
Maybe I also could try the code sourcery one, but there is no
reference for the 'legacy 68k' family on their download page (only
coldfire).

Any m68k targeted compiler should be able to generate code for any
family member with the right command line options. With the bundled
toolchains you may not have the libs generated for your specific
CPU member though.

Regards
Greg

------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close, FAX: +61 7 3891 3630
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com

Luis Alves

2012-05-17 02:58:34 UTC

Hi Greg,

I've built a new toolchain using the latest tools and gcc-4.6.4
(gcc-4.7.0 is giving me compiler internal errors!).
But unfortunately the results are the same (bad assembly code - It
look it is producing 68020 code, since when I use the -m68020 flag,
the resulting assembly code is equal!)

I've downgraded gcc to 4.2.4 (the version I was using before this
toolchain quest) and it works (produces correct assembly code).
I don't know what is the latest working version for the 68000 targets.
Maybe I'll go one by one until I find the broken one...

I guess this is related to gcc so I've reported it as a bug it in the
gcc bugzilla (Bug 53386).

Do you have any further suggestion?

Thanks and regards,
Luis Alves

Post by Luis Alves
Hi Greg,

Post by Greg Ungerer
What are the compiler options supplied to gcc?
(If you make the kernel with V=1 then you get the full command
line trace)

m68k-uclinux-gcc -Wp,-MD,net/sunrpc/.sysctl.o.d ?-nostdinc -isystem
/usr/local/lib/gcc/m68k-uclinux/4.5.1/include
-I/root/m68k/20120401/uClinux-dist/linux-3.x/arch/m68k/include
-Iarch/m68k/include/generated -Iinclude ?-include
/root/m68k/20120401/uClinux-dist/linux-3.x/include/linux/kconfig.h
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -fno-delete-null-pointer-checks -O2 -m68000 -pipe
-DUTS_SYSNAME=\"uClinux\" -D__uClinux__ -Wframe-larger-than=1024
-fno-stack-protector -fomit-frame-pointer
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -DCC_HAVE_ASM_GOTO ? ?-D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(sysctl)"
-D"KBUILD_MODNAME=KBUILD_STR(sunrpc)" -c -o net/sunrpc/sysctl.o
net/sunrpc/sysctl.c
I guess the -m68000 should be enough, but it isn't.
I've compiled the same file with -m68020 and the output assembly is
exactly the same.

I just confirmed and there is no support for non-coldfire cpu's in
code sourcery toolchain...

Post by Greg Ungerer
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer ?-- ?Principal Engineer ? ? ? ?EMAIL: ? ? gerg at snapgear.com
SnapGear Group, McAfee ? ? ? ? ? ? ? ? ? ? ?PHONE: ? ? ? +61 7 3435 2888
8 Gardner Close, ? ? ? ? ? ? ? ? ? ? ? ? ? ?FAX: ? ? ? ? +61 7 3891 3630
Milton, QLD, 4064, Australia ? ? ? ? ? ? ? ?WEB: http://www.SnapGear.com

Regards,
Luis Alves

Greg Ungerer

2012-05-17 06:45:07 UTC

Hi Luis,

Post by Luis Alves
I've built a new toolchain using the latest tools and gcc-4.6.4
(gcc-4.7.0 is giving me compiler internal errors!).
But unfortunately the results are the same (bad assembly code - It
look it is producing 68020 code, since when I use the -m68020 flag,
the resulting assembly code is equal!)

That is bad...

Post by Luis Alves
I've downgraded gcc to 4.2.4 (the version I was using before this
toolchain quest) and it works (produces correct assembly code).
I don't know what is the latest working version for the 68000 targets.
Maybe I'll go one by one until I find the broken one...

Ouch, doesn't sound like much fun.

Post by Luis Alves
I guess this is related to gcc so I've reported it as a bug it in the
gcc bugzilla (Bug 53386).
Do you have any further suggestion?

The gcc compile options looked good to me. If you have -m68000 set
the you should be getting code that is good for 68000. I guess the
code generation is at least only using the correct set of 68000
instructions.

Choosing a different optimization level may change the instruction/
addressing modes used. But really that would just be a work around.

Otherwise I would suggest sticking with 4.2.4 if that works.

Regards
Greg

Post by Luis Alves
Hi Greg,

Post by Greg Ungerer
What are the compiler options supplied to gcc?
(If you make the kernel with V=1 then you get the full command
line trace)

m68k-uclinux-gcc -Wp,-MD,net/sunrpc/.sysctl.o.d ??-nostdinc -isystem
/usr/local/lib/gcc/m68k-uclinux/4.5.1/include
-I/root/m68k/20120401/uClinux-dist/linux-3.x/arch/m68k/include
-Iarch/m68k/include/generated -Iinclude ??-include
/root/m68k/20120401/uClinux-dist/linux-3.x/include/linux/kconfig.h
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -fno-delete-null-pointer-checks -O2 -m68000 -pipe
-DUTS_SYSNAME=\"uClinux\" -D__uClinux__ -Wframe-larger-than=1024
-fno-stack-protector -fomit-frame-pointer
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -DCC_HAVE_ASM_GOTO ?? ??-D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(sysctl)"
-D"KBUILD_MODNAME=KBUILD_STR(sunrpc)" -c -o net/sunrpc/sysctl.o
net/sunrpc/sysctl.c
I guess the -m68000 should be enough, but it isn't.
I've compiled the same file with -m68020 and the output assembly is
exactly the same.

I just confirmed and there is no support for non-coldfire cpu's in
code sourcery toolchain...

Post by Greg Ungerer
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer ??-- ??Principal Engineer ?? ?? ?? ??EMAIL: ?? ?? gerg at snapgear.com
SnapGear Group, McAfee ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??PHONE: ?? ?? ?? +61 7 3435 2888
8 Gardner Close, ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??FAX: ?? ?? ?? ?? +61 7 3891 3630
Milton, QLD, 4064, Australia ?? ?? ?? ?? ?? ?? ?? ??WEB: http://www.SnapGear.com

Regards,
Luis Alves

Luis Alves

2012-05-17 14:21:12 UTC

Hi Greg,

Yes, that file exists in the sources gcc-<version>/gcc/config/m68k/uclinux.h
I've changed those flags and it works (at least in a small test with
the first pass gcc).

But take a look at the comments in my bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386

Someone says that it is related to the ABI change in gcc >= 4.3.x and
that I should use as target 'm68k-uclinuxoldabi' and
--with-cpu=m68000.

For now I've just changed the flags in the header file... maybe I'll
try building it with that weird target (m68k-uclinuxoldabi).

Regards,
Luis Alves

Post by Ivica Eftimovski
Hi Luis,

A guy just posted a comment in my bug report. It happens that it is a

/* for 68k machines this only needs to be TRUE for the 68000 */
#undef STRICT_ALIGNMENT
#define STRICT_ALIGNMENT 0
#undef M68K_HONOR_TARGET_STRICT_ALIGNMENT
#define M68K_HONOR_TARGET_STRICT_ALIGNMENT 0

I don't know if this will affect the build for coldfire targets. If it
does then from now on the 68000 should be excluded from the coldfire
toolchains to avoid this issues.
I'll build a nice toolchain for the 68000 and then make some more tests.

Wow, that is interesting. I don't quite see why that should not
always be set, otherwise how does specifying "-m68000" work at all.
Is there a config/m68k/uclinux.h file? ?I don't have the sources
handly right now to check.
Regards
Greg

Hi Luis,

That is bad...

Ouch, doesn't sound like much fun.

Post by Luis Alves
I guess this is related to gcc so I've reported it as a bug it in the
gcc bugzilla (Bug 53386).
Do you have any further suggestion?

The gcc compile options looked good to me. If you have -m68000 set
the you should be getting code that is good for 68000. I guess the
code generation is at least only using the correct set of 68000
instructions.
Choosing a different optimization level may change the instruction/
addressing modes used. But really that would just be a work around.
Otherwise I would suggest sticking with 4.2.4 if that works.
Regards
Greg

Post by Luis Alves
Hi Greg,

Post by Greg Ungerer
What are the compiler options supplied to gcc?
(If you make the kernel with V=1 then you get the full command
line trace)

m68k-uclinux-gcc -Wp,-MD,net/sunrpc/.sysctl.o.d ?????-nostdinc -isystem
/usr/local/lib/gcc/m68k-uclinux/4.5.1/include
-I/root/m68k/20120401/uClinux-dist/linux-3.x/arch/m68k/include
-Iarch/m68k/include/generated -Iinclude ?????-include
/root/m68k/20120401/uClinux-dist/linux-3.x/include/linux/kconfig.h
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -fno-delete-null-pointer-checks -O2 -m68000 -pipe
-DUTS_SYSNAME=\"uClinux\" -D__uClinux__ -Wframe-larger-than=1024
-fno-stack-protector -fomit-frame-pointer
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -DCC_HAVE_ASM_GOTO ????? ?????-D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(sysctl)"
-D"KBUILD_MODNAME=KBUILD_STR(sunrpc)" -c -o net/sunrpc/sysctl.o
net/sunrpc/sysctl.c
I guess the -m68000 should be enough, but it isn't.
I've compiled the same file with -m68020 and the output assembly is
exactly the same.

I just confirmed and there is no support for non-coldfire cpu's in
code sourcery toolchain...

Post by Greg Ungerer
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer ?????-- ?????Principal Engineer ????? ????? ?????
?????EMAIL: ????? ?????
gerg at snapgear.com
SnapGear Group, McAfee ????? ????? ????? ????? ????? ????? ????? ?????
????? ????? ?????PHONE: ????? ????? ?????
+61 7 3435 2888
8 Gardner Close, ????? ????? ????? ????? ????? ????? ????? ????? ?????
????? ????? ????? ????? ?????FAX: ????? ????? ?????
????? +61 7 3891 3630
Milton, QLD, 4064, Australia ????? ????? ????? ????? ????? ????? ?????
http://www.SnapGear.com

Regards,
Luis Alves

--
------------------------------------------------------------------------
Greg Ungerer ??-- ??Principal Engineer ?? ?? ?? ??EMAIL: ?? ?? gerg at snapgear.com
SnapGear Group, McAfee ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??PHONE: ?? ?? ?? +61 7 3435 2888
8 Gardner Close, ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??FAX: ?? ?? ??
?? +61 7 3891 3630
http://www.SnapGear.com

Lennart Sorensen

2012-05-17 14:54:18 UTC

Post by Luis Alves
Hi Greg,
Yes, that file exists in the sources gcc-<version>/gcc/config/m68k/uclinux.h
I've changed those flags and it works (at least in a small test with
the first pass gcc).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386
Someone says that it is related to the ABI change in gcc >= 4.3.x and
that I should use as target 'm68k-uclinuxoldabi' and
--with-cpu=m68000.
For now I've just changed the flags in the header file... maybe I'll
try building it with that weird target (m68k-uclinuxoldabi).

gcc 4.3 at least change the size of floating point from 80 to 64bit on
coldfire (and possibly on m68k in general, not sure), and also made some
changes in other things.

gcc 4.2 would fail to compile some programs for me, running out of space
in the offset table as far as I can tell, while gcc 4.3 has never had
any problems with that. My understanding is that gcc 4.3 switched to a
different way of handling the GOT which works much better, but is almost
certainly incompatible with the old method. gcc 4.3 also optimizes a
lot more in m68k than 4.2 (I had to insert memory barriers in uboot to
convince gcc 4.3 not to rearrange seemingly unrelated memory read and
writes in the memory controller setup, where as gcc 4.2 did so little
optimization that it never had any issue). gcc 4.3 didn't do anything
wrong, the code simply wasn't specific enough about what it wanted.

So I like the gcc 4.3 improvements over 4.2.

--
Len Sorensen

Greg Ungerer

2012-05-18 05:17:34 UTC

Hi Luis,

Post by Luis Alves
Yes, that file exists in the sources gcc-<version>/gcc/config/m68k/uclinux.h
I've changed those flags and it works (at least in a small test with
the first pass gcc).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386

Yeah, interesting discussion :-)

Post by Luis Alves
Someone says that it is related to the ABI change in gcc>= 4.3.x and
that I should use as target 'm68k-uclinuxoldabi' and
--with-cpu=m68000.
For now I've just changed the flags in the header file... maybe I'll
try building it with that weird target (m68k-uclinuxoldabi).

Well, I consider it a bug still (I will probably make some gcc people
unhappy :-( The ABI change itself doesn't really have anything to do
with it. If you use "gcc -m68000" to generate code that cannot work
then it is a bug. I couldn't in good conscience call that a configuration
error (though we know you can fix it by changing the that STRICT_ALIGNMENT
setting).

But that is just my take on it.

Regards
Greg

Post by Ivica Eftimovski
Hi Luis,

A guy just posted a comment in my bug report. It happens that it is a

Wow, that is interesting. I don't quite see why that should not
always be set, otherwise how does specifying "-m68000" work at all.
Is there a config/m68k/uclinux.h file? ??I don't have the sources
handly right now to check.
Regards
Greg

Hi Luis,

That is bad...

Ouch, doesn't sound like much fun.

Post by Luis Alves
I guess this is related to gcc so I've reported it as a bug it in the
gcc bugzilla (Bug 53386).
Do you have any further suggestion?

The gcc compile options looked good to me. If you have -m68000 set
the you should be getting code that is good for 68000. I guess the
code generation is at least only using the correct set of 68000
instructions.
Choosing a different optimization level may change the instruction/
addressing modes used. But really that would just be a work around.
Otherwise I would suggest sticking with 4.2.4 if that works.
Regards
Greg

Post by Luis Alves
Hi Greg,

Post by Greg Ungerer
What are the compiler options supplied to gcc?
(If you make the kernel with V=1 then you get the full command
line trace)

m68k-uclinux-gcc -Wp,-MD,net/sunrpc/.sysctl.o.d ???????????-nostdinc -isystem
/usr/local/lib/gcc/m68k-uclinux/4.5.1/include
-I/root/m68k/20120401/uClinux-dist/linux-3.x/arch/m68k/include
-Iarch/m68k/include/generated -Iinclude ???????????-include
/root/m68k/20120401/uClinux-dist/linux-3.x/include/linux/kconfig.h
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -fno-delete-null-pointer-checks -O2 -m68000 -pipe
-DUTS_SYSNAME=\"uClinux\" -D__uClinux__ -Wframe-larger-than=1024
-fno-stack-protector -fomit-frame-pointer
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -DCC_HAVE_ASM_GOTO ??????????? ???????????-D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(sysctl)"
-D"KBUILD_MODNAME=KBUILD_STR(sunrpc)" -c -o net/sunrpc/sysctl.o
net/sunrpc/sysctl.c
I guess the -m68000 should be enough, but it isn't.
I've compiled the same file with -m68020 and the output assembly is
exactly the same.

I just confirmed and there is no support for non-coldfire cpu's in
code sourcery toolchain...

Post by Greg Ungerer
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer ???????????-- ???????????Principal Engineer ??????????? ??????????? ???????????
???????????EMAIL: ??????????? ???????????
gerg at snapgear.com
SnapGear Group, McAfee ??????????? ??????????? ??????????? ??????????? ??????????? ??????????? ??????????? ???????????
??????????? ??????????? ???????????PHONE: ??????????? ??????????? ???????????
+61 7 3435 2888
8 Gardner Close, ??????????? ??????????? ??????????? ??????????? ??????????? ??????????? ??????????? ??????????? ???????????
??????????? ??????????? ??????????? ??????????? ???????????FAX: ??????????? ??????????? ???????????
??????????? +61 7 3891 3630
Milton, QLD, 4064, Australia ??????????? ??????????? ??????????? ??????????? ??????????? ??????????? ???????????
http://www.SnapGear.com

Regards,
Luis Alves

--
------------------------------------------------------------------------
Greg Ungerer ?????-- ?????Principal Engineer ????? ????? ????? ?????EMAIL: ????? ?????
gerg at snapgear.com
SnapGear Group, McAfee ????? ????? ????? ????? ????? ????? ????? ????? ????? ????? ?????PHONE: ????? ????? ?????
+61 7 3435 2888
8 Gardner Close, ????? ????? ????? ????? ????? ????? ????? ????? ????? ????? ????? ????? ????? ?????FAX: ????? ????? ?????
????? +61 7 3891 3630
http://www.SnapGear.com

--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com

David Howells

2012-05-15 09:33:34 UTC