GCC 4.1.1 m68k-rtems generating invalid code for -m5307 proce ssor ?

Kirspel, Kevin kevin.kirspel at optimedical.com
Mon Jun 25 17:50:06 UTC 2007

Here is a response from the CodeSourcery guys about this issue.  

This instruction does not occur in any of the memset implementations we
ship; I suspect it is a problem with your configuration when you rebuilt the

If I'm reading the disassembler table correctly, that is bftst - an
instruction present on the 68020 but not on ColdFire.

Daniel Jacobowitz


I performed the following steps during the build process:

- unarchived binutils. 
- built binutils with the following configure statement: 

configure --target=m68k-rtems --prefix=/usr/local. 

- installed binutils. 
- unarchived gcc and newlib. 
- created symbolic link for newlib within gcc. 
- built gcc with the following configure statement: 

configure  --target=m68k-rtems --with-gnu-as --with-gnu-ld --with-newlib
--verbose --enable-threads --enable-languages="c,c++" --prefix=/usr/local. 

- installed gcc. 
- unarchived RTEMS. 
- built RTEMS with the following configure statement: 

configure --target=m68k-rtems --disable-posix --disable-itron
--disable-networking --disable-cxx --enable-rtemsbsp=mcf5329EVB

If the CodeSourcery guy is right, it sounds like I'm grabbing the 68020
library objects instead of the 5307 coldfire libraries.  Does the m68k-rtems
target generate 5307 libraries?  Do have to modify the m68k-rtems target in
gcc to build the coldfire libraries?  Is there a configure option that will
build them?

-----Original Message-----
From: Chris Johns [mailto:chrisj at rtems.org] 
Sent: Monday, June 25, 2007 9:18 AM
To: Ian Caddy
Cc: Kirspel, Kevin; 'rtems-users at rtems.org'
Subject: Re: GCC 4.1.1 m68k-rtems generating invalid code for -m5307
processor ?

Ian Caddy wrote:
> Hi Kevin,
> We also use the 5307 for our system, and are currently using gcc 4.1.1 
> and we don't see your problem.
> Below is the disassembly for the start of memset similar to yours:
> 080bd600 <memset>:
>   80bd600:	4e56 0000      	linkw %fp,#0
>   80bd604:	2f03           	movel %d3,%sp at -
>   80bd606:	2f02           	movel %d2,%sp at -
>   80bd608:	262e 0008      	movel %fp@(8),%d3
>   80bd60c:	226e 0010      	moveal %fp@(16),%a1
>   80bd610:	2203           	movel %d3,%d1
>   80bd612:	4282           	clrl %d2
>   80bd614:	142e 000f      	moveb %fp@(15),%d2
>   80bd618:	7003           	moveq #3,%d0
>   80bd61a:	b089           	cmpl %a1,%d0
>   80bd61c:	6404           	bccs 80bd622 <memset+0x22>
>   80bd61e:	c083           	andl %d3,%d0
>   80bd620:	6712           	beqs 80bd634 <memset+0x34>
>   80bd622:	4a89           	tstl %a1
>   80bd624:	6758           	beqs 80bd67e <memset+0x7e>
>   80bd626:	1002           	moveb %d2,%d0
>   80bd628:	2041           	moveal %d1,%a0
>   80bd62a:	d3c1           	addal %d1,%a1
> Note that ours seems to be producing valid code just after the first bcc.

The asm comes back into sync at:

   80bd620:	6712           	beqs 80bd634 <memset+0x34>

and so there are 2 extra bytes in the output. This is not just a corruption,

it is an extra opcodes. See how the original offset is more:

400149ee:       6712            beqs 40014a02 <memset+0x36>

The +0x34 for your code and +0x36 for the posted code. Ian, the rtems-4.8 
tools generate the same code you.

> You indicated that you built your tools.  Have you tried the standard 
> toolsets from the RTEMS website?

The rpms on the RTEMS build machine show:

[chrisjohns at england build]$ ls /opt/rtems-4.7/m68k-rtems4.7/lib/
crt0.o  ldscripts  libc.a  libg.a  libm.a  m5200  m68000  m68030  m68040 
m68060  mcpu32  msoft-float
[chrisjohns at england build]$ ls /opt/rtems-4.8/m68k-rtems4.8/lib/
crt0.o  ldscripts  libc.a  libg.a  libm.a  m5200  m68000  m68030  m68040 
m68060  mcpu32  msoft-float

No V3 specific builds in the released tool sets.

> regards,
> Ian Caddy
> Kirspel, Kevin wrote:
>> I have built the following environment for the m68k-rtems target:
>> binutils-2.17       with patch binutils-2.17-rtems4.7-20061021.diff
>> gcc-4.1.1           with patch gcc-core-4.1.1-rtems4.7-20070102.diff
>> newlib-1.14.0     with patch newlib-1.15.0-rtems4.7-20070208.diff
>> I have created an MCF5329EVB BSP in the RTEMS 4.7 branch.  Since GCC 
>> 4.1.1 does not support the MCF5329 processor I had to use the -m5307 

And GCC should not support CPU types based on a mix of on-chip hardware. If 
the core had extra executed instructions *and* gcc could use them then that 
would be a reason to consider a new machine option.

Does the -m5307 actually cause GCC to generate different code for RTEMS ? In

the gcc 4.2.0 m68k back end code I can see differences for the Coldfire FPU,

and a HW DIV but that is all. I am no gcc expert so it may pay to ask on the

gcc list.

>> option to generate V3 code ( I think this should work ).  The RTEMS 
>> compilation was successfully.  Using GDB, I ran the hello.exe sample 
>> test.  The hello.exe fails during the _IO_Manager_initialization() 
>> function where is calls memset().  After single stepping through 
>> memset(), the programmed dies when the PC reaches the instruction at 
>> 0x400149ea.  I disassembled hello and got the following output for
>> 400149cc <memset>:
>> 400149cc:         4e56 0000         linkw %fp,#0
>> 400149d0:         2f03                  movel %d3,%sp at -
>> 400149d2:         2f02                  movel %d2,%sp at -
>> 400149d4:         262e 0008         movel %fp@(8),%d3
>> 400149d8:         226e 0010         moveal %fp@(16),%a1
>> 400149dc:         2203                 movel %d3,%d1
>> 400149de:         4282                 clrl %d2
>> 400149e0:         142e 000f          moveb %fp@(15),%d2
>> 400149e4:         7003                 moveq #3,%d0
>> 400149e6:         b089                 cmpl %a1,%d0
>> 400149e8:         6406                 bccs 400149f0 <memset+0x24>
>> 400149ea:         e8c3                 0164303
>> 400149ec:         0782                 bclr %d3,%d2

More information about the users mailing list