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
tools.
If I'm reading the disassembler table correctly, that is bftst - an
instruction present on the 68020 but not on ColdFire.
--
Daniel Jacobowitz
CodeSourcery
----------------------------------------------------------------
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
--prefix=/usr/local.
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
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
>>
More information about the users
mailing list