Re: [PATCH 00/22] Update of the SPARC SIS simulator

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

On 17 Feb 2015 15:40, Jiri Gaisler wrote:
> On 02/17/2015 09:54 AM, Mike Frysinger wrote:
> > On 17 Feb 2015 08:44, Jiri Gaisler wrote:
> >> This is a 22-part patch that brings the sis simulator into working
> >> order, and adds support for emulation of the leon2 and leon3 cpus.
> >>
> >> The sis simulator was written by me in the mid 90's, to emulate the erc32
> >> processor (SPARC V7). It was included into gdb by Cygnus (Stan Shebs?),
> >> and adapted to also emulate the Fujistu Sparlite processor. The simulator
> >> has not been actively maintained for about 15 years, and suffered some
> >> bit-rot. It's primary use has been for RTEMS development. The erc32
> >> processor is now becoming obsolete, and being replaced by leon2 and
> >> leon3 cpus in many ESA and NASA missions. These patches will
> >> allow sis to be useful again, and support the newer leon2/3 processor.
> >
> > it would be nice if there was a testsuite.  how are you verifying things
> > continue to work and there are no regressions ?
> >
> > should be easy to add some basic .s files to verify insns ... lots of examples
> > in the testsuite/sim/ subdirs already.
>
> I have a set of pre-compiled binaries to test for basic SPARC and FPU
> compliance. On top of that, I run the RTEMS testsuite which is rather
> extensive. Is it acceptable to drop a few SPARC binaries to the gdb
> testuite/sim, or does it all have to be in source? The test applications
> are typically written in C, so we would need a full C cross-compiler to
> build them ...

unfortunately, it would have to be source, and i imagine the FSF would want the 
copyright for it.  i guess to mitigate, we could update the erc32 README with 
notes for how to test things.

the sim prefers .s/.S files because they can be assembled+linked entirely on 
their own (in the combined binutils+gdb tree), but .c files are certainly not 
banned.  if you look in the bfin/ subdir, you can see how i handle missing 
compiler support and fall back to SKIPing those tests.

i tend to prefer `make check` myself so that when i'm making common changes, i 
can run all the builtin testsuites to have some confidence i'm not breaking 
people.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]