Re: Simulator testing for sh and sh64

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

This is about sh and sh64 GDB sim testing for the whole toolchain.  (I
also do have sh4a hardware available, where testing is working fine.)
Kaz, could you please have a look whether this looks basically sane, that
my assumptions and the results I'm getting are about right, etc.?


On Wed, 22 Feb 2012 09:39:29 -0700, Kevin Buettner <kevinb@redhat.com> wrote:
> On Wed, 22 Feb 2012 15:52:03 +0100
> Thomas Schwinge <thomas@codesourcery.com> wrote:
> 
> > How do you configure the toolchain's components for the sim testing?
> 
> I use --target=sh-elf .
> 
> When it comes time to run the tests, do:
> 
> make check RUNTESTFLAGS="--target_board=sh-sim"

OK, that matches what I'm doing (simple enough), and that works for me,
too.


With all-current sources (CVS HEAD, svn trunk, Git master, as
appropriate), I get 707 unexpected failures in g++ testing (a lot of
execution tests, as it seems), 204 in gcc, 434 in gdb (I'm currently
working on improving that), 41 in ld (seems that some test harness
problem is involved; get a lot of: ``sh-elf-ld: cannot find sh-unknown.o:
No such file or directory''), 322 in libstdc++, 3 in newlib.  So far, so
good.


> > And, any quick suggestion for a sh64 sim testing configuration, too?  My
> > attempt so far only results in a series of SIGILL...

Kaz, is my understanding correct, that I simply use sh64-elf as target,
and again the sh-sim board?  Should I be setting a specific CPU when
configuring GCC, or any other customization?


Building all-current sources comes to a halt as follows:

    /scratch/tschwing/FM_sh64-elf/obj/gcc-first-mainline-0-sh64-elf-i686-pc-linux-gnu/./gcc/xgcc -B/scratch/tschwing/FM_sh64-elf/obj/gcc-first-mainline-0-sh64-elf-i686-pc-linux-gnu/./gcc/ -B/scratch/tschwing/FM_sh64-elf/install/sh64-elf/bin/ -B/scratch/tschwing/FM_sh64-elf/install/sh64-elf/lib/ -isystem /scratch/tschwing/FM_sh64-elf/install/sh64-elf/include -isystem /scratch/tschwing/FM_sh64-elf/install/sh64-elf/sys-include --sysroot=/scratch/tschwing/FM_sh64-elf/install/sh64-elf   -g -O2 -ml -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -mieee -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -mieee -I. -I. -I../../.././gcc -I/scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc -I/scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/. -I/scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/../gcc -I/scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o _powisf2.o -MT _powisf2.o -MD -MP -MF _powisf2.dep -DL_powisf2 -c /scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/libgcc2.c 
    /scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/libgcc2.c: In function '__powisf2':
    /scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/libgcc2.c:1779:1: error: unrecognizable insn:
    (insn 10 9 11 3 (set (reg:SI 162 [ D.2769 ])
            (abs:SI (reg/v:SI 168 [ m ]))) /scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/libgcc2.c:1770 -1
         (nil))
    /scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/libgcc2.c:1779:1: internal compiler error: in extract_insn, at recog.c:2123


Stepping back to using the 4.5 GCC branch and otherwise all-current
sources, it compiles, and I get 76 unexpected failures in g++ (a lot of
``ld: section .stack loaded at [0000000000080000,0000000000080003]
overlaps section .text loaded at [0000000000001060,00000000000ec0bf]''),
119 in gcc, 41 in ld, 1185 in libstdc++ (the section overlap issue again,
it seems), 3 in newlib, and GDB testing totally breaks down: I'm
receiving a lot of ``Program received signal SIGILL, Illegal
instruction''; from a quick investigation, it seems that GDB is patching
the breakpoints at addresses that are 2 bytes offset from where they
meant to go.  I'll have a look at this.


Moving a bit forward by using the 4.6 GCC branch and otherwise
all-current sources, it compiles, and the test results look similar to
GCC 4.5's.


This means, for sh-elf sim testing, we have a bit too many failures in
GCC and GDB, and some ld test harness issue.  For sh64-elf we have a GCC
trunk ICE, some section overlap issue, and even more GDB issues.


GrÃÃe,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature