sh and newlib 1.8.1

[Joel Sherrill <joel@OARcorp.com>]

I asked the  RTEMS SH maintainer to look at the sh code in 1.8.1 and he
pointed out the following.  It appears to him that there is still code
which is not valid for the sh1 in some of the machine specific files.

--joel

---------- Forwarded message ----------
Date: Wed, 08 Jul 1998 11:58:06 +0200
From: Ralf Corsepius <corsepiu@faw.uni-ulm.de>
To: Joel Sherrill <joel@OARcorp.com>
Subject: Re: newlib 1.8.1

Joel Sherrill wrote:

> Hi,
>
> I am starting to wade through newlib 1.8.1 and have noticed that the
> machine specific sh code is very different. I do not know if it has the
> same problems you encountered or not.
>
> Could you please eyeball the code and let me know?

Here is a quick review:

I checked the files under the following sub-directories:
./newlib-1.8.1/newlib/libc/machine/sh
./newlib-1.8.1/newlib/libc/sys/sh
./newlib-1.8.1/libgloss/sh


Now a bit more in detail:
* ./newlib-1.8.1/libgloss/sh:
Some minor changes to linkerscripts were added, they don't affect us, as we
have our own "linkcmds".

* ./newlib-1.8.1/newlib/libc/sys/sh:
crt0.S: SH3E/SH4 floating point register setup was added. This doesn't affect
us (nor does it affect SH2/SH3), because sh-rtems nether supports the SH3E
nor do we use this crt0.S. Perhaps we should cut and past the sections of
this crt0.S enclosed by #if __SH3E__  #endif into our sh/start.S. But AFAIS
this code fragment calls a function called __set_fpcrs which I couldn't find
anywhere in newlib-1.8.1 => Most probably a BUG in newlib which doesn't
affect rtems.

* ./newlib-1.8.1/newlib/libc/machine/sh:
memcpy.S: Massively modified. I am insecure about what I see. However, I
didn't discover any critical asm-instruction so far, but this deserves to be
tested on real SH1 CPUs, before giving any further statement.  I am
suspicious.

memset.S: The old "dt"-bug is in again - SH1 doesn't have this instruction -
this was the initial cause of my newlib-1.8.0 patch, which is part of rtems'
newlib patch  and which I also mailed to newlib@cygnus.com. I thought it had
been merged because I once received a merger notice from somebody at cygnus,
but obviously it isn't. => A BUG in newlib which affects rtems



CONCLUSION:

SH-support in newlib is broken again. The memset.S bug is fatal and needs to
be locally fixed by us, memcpy.S is critical but the actual state is not yet
clear to me, all other issues don't affect us, AFAIS.


TODO:

For the next rtems' newlib patch you have to keep the sh/memset.S patch, but
you can drop all other sh related newlib patches. I didn't yet check the
Makefiles and configuration files, but AFAIR rtems' newlib-1.8.0 patch didn't
contain any configuration/Makefile related sh-patches.


Ralf.

--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
mailto:corsepiu@faw.uni-ulm.de           FAX: +49/731/501-999
http://www.faw.uni-ulm.de