This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Before posting, please read the FAQ:
and search the list archive:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]