Re: Simulator testing for sh and sh64

[Thomas Schwinge]

Hi!

On Thu, 23 Feb 2012 08:42:53 +0900, Kaz Kojima  wrote:
> Thomas Schwinge  wrote:
> > 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?
> 
> I used sh64-sim board for sh64-elf.  sh64-sim.exp baseboard can
> be seen in
> 
> http://lists.gnu.org/archive/html/dejagnu/2008-02/msg00056.html

I gave both sh-sim and sh64-sim a try, and -- if I'm reading correctly
between all the noise -- there isn't really much difference in the
testresults depending on which of the two is being used.


> > 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.
> 
> Yep.  About sh64, I had used sh64-linux as my testing target, but
> unfortunately that real sh64 system stopped working after the earthquake.

Ouch.  :-/


Grüße,
 Thomas


pgpkq7GpdnHMY.pgp
Description: PGP signature

Re: Simulator testing for sh and sh64

[Thomas Schwinge]

Hi!

On Wed, 22 Feb 2012 20:29:11 +0100, I wrote:
> On Wed, 22 Feb 2012 09:39:29 -0700, Kevin Buettner  wrote:
> > On Wed, 22 Feb 2012 15:52:03 +0100
> > Thomas Schwinge  wrote:
> > > And, any quick suggestion for a sh64 sim testing configuration, too?  My
> > > attempt so far only results in a series of SIGILL...

> 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.

I did, but it's turning into a rat's nest -- sh64-tdep needs several
years of catch-up, as it seems.  The SIGILL issue that I briefly
described is what Kevin (hello, hello!) :-) fixed for MIPS in
486ee7f3437358941f0762ace2550170ef474de1,
; basically
the issue is that setting PC's bit 0 in sh64_elf_make_msymbol_special for
ISA32 (SHmedia) code will confuse GDB's msymbol machinery, resulting
first in a 1-byte offset, which is later ``fixed'' into the 2-byte offset
that I mentioned.  And patching a 4-byte breakpoint instruction into the
middle of two 4-byte instructions is very likely to cause a SIGILL.

I have begun hacking into sh64-tdep the same kind of changes that Kevin
did for MIPS, but there's more to do, as I'm now seeing ``odd addresses''
for symbols coming out of GDB's symbol table lookup, find_pc_line.
Again, the addresses point into the middle of 4-byte instructions.  This
may be an issue with the debugging information GCC generates, or it may
be something else.  For the time being, I'm stopping at this point.

Anyway, the patch for sh-tdep that I posted in
 (at the end)
also applies to sh64-tdep -- shall I commit the equivalent sh64-tdep
change without any testsuite testing, or let it bit-rot some more?


Grüße,
 Thomas


pgp8c7ErNZSPK.pgp
Description: PGP signature

Re: Simulator testing for sh and sh64

[Kaz Kojima]

Thomas Schwinge  wrote:
> 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.?

You are right, I think.

> 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?

I used sh64-sim board for sh64-elf.  sh64-sim.exp baseboard can
be seen in

http://lists.gnu.org/archive/html/dejagnu/2008-02/msg00056.html

> 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.

Yep.  About sh64, I had used sh64-linux as my testing target, but
unfortunately that real sh64 system stopped working after the earthquake.

Regards,
kaz

Re: Simulator testing for sh and sh64

[Thomas Schwinge]

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  wrote:
> On Wed, 22 Feb 2012 15:52:03 +0100
> Thomas Schwinge  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 [0008,00080003]
overlaps section .text loaded at [1060,000ec0bf]''),
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


pgp9mRku0FfBJ.pgp
Description: PGP signature