This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
SH3 Toolchain Reliability
- From: Kelvin Lawson <klawson at ad-holdings dot co dot uk>
- To: ecos-discuss at sources dot redhat dot com
- Date: Mon, 02 Feb 2004 18:21:11 +0000
- Subject: [ECOS] SH3 Toolchain Reliability
Hi All,
Is anyone getting reliable code generated by sh-elf-gcc on cygwin ?
I have had to vary the optimisation level for different eCos packages in
order to get a working system:
. printf(), fprintf() etc did not work properly at -O2. The sprintf
tests failed due to various padding issues, and sometimes arguments were
turned into a lot of zeroes. Building with -O0 fixed this.
. I found bad assembly generated in the FreeBSD stack at -O0 so have put
this up to -O2. sosend() in uipc_socket.c generated the following code:
space -= len;
<cyg_sosend+2148>: mov #64,r3
<cyg_sosend+2150>: add r14,r3
<cyg_sosend+2152>: mov #64,r3
<cyg_sosend+2154>: add r14,r3
<cyg_sosend+2156>: mov.l @(0,r3),r1
<cyg_sosend+2158>: mov.l @(4,r3),r3
<cyg_sosend+2160>: sub r3,r1
<cyg_sosend+2162>: mov.l r1,@(0,r3)
r3 is used for both a frame pointer, and temporary storage for the 'len'
variable. When the subtraction is done, the compiler has forgotten that
r3 now contains 'len' and is using it as a frame pointer. The last line
therefore could store the value anywhere and generate a SIGBUS error.
I'm concerned about having to vary the optimisation levels just to get
some working output, so I'd be interested to hear if anyone has seen
these problems, and possibly solved them. Perhaps later versions of gcc
are more reliable ? The eCos site recommends 3.2.1 though.
I'm using the ecoscentric toolchain (with gcc-3.2.1), and the latest
cygwin (1.5.7). The target is a custom 7709S board - we based the HAL on
the SE77x9.
Cheers,
Kelvin.
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss