Re: Simulator testing for sh and sh64

Thomas Schwinge
2012-02-23T19:50:21Z

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

Hi!

On Wed, 22 Feb 2012 20:29:11 +0100, I wrote:
> 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:
> > > 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,
<http://sourceware.org/ml/gdb-patches/2010-12/msg00202.html>; 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
<http://sourceware.org/ml/gdb-patches/2012-02/msg00299.html> (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?