GCC 4.1.1 m68k-rtems generating invalid code for -m5307 processor ?

[Chris Johns]

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 memset():
>>
>>  
>>
>> 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
>>