[ECOS] SH3 Toolchain Reliability

[Kelvin Lawson <klawson at ad-holdings dot co dot uk>]

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