Re: gdb & gdbserver for s390 31 & 64 bit

[Andrew Cagney <ac131313@cygnus.com>]

Ok,

> http://www10.software.ibm.com/developerworks/opensource/linux390/exp_src.html
> Patch:    gdb-5.1pre-050901-s390.tar.gz (09/11/2001)
>      MD5: 886251f3719a754dd65a69df462ceac1
> 

I've now re-created this and added the ChangeLogs:

> 2001-09-26  Andrew Cagney  <ac131313@redhat.com>
> 
>         From 2001-08-22 D.J. Barrow <djbarrow@de.ibm.com>:
>         * config.sub: Added S/390 31 & 64 bit target.
> 
> 2001-09-26  Andrew Cagney  <ac131313@redhat.com>
> 
>         From 2001-07-09 D.J. Barrow <djbarrow@de.ibm.com>:
> 
>         * s390-nat.c: New file Added for S/390 31 & 64 bit target.
>         * s390-tdep.c: Likewise.
>         * config/s390/nm-linux.h: Likewise.     
>         * config/s390/s390x.mt: Likewise.
>         * config/s390/tm-linux.h : Likewise. 
>         * config/s390/xm-linux.h: Likewise
>         * config/s390/s390.mh: Likewise.
>         * config/s390/s390.mt: Likewise.
>         * config/s390/tm-s390.h: Likewise.
>         * config.in Added definitions for S/390 31 & 64 bit target.
>         * configure.host: Likewise.
>         * configure.in: Likewise.
>         * configure.tgt: Likewise.
> 
>         * gdbarch.sh: Fixed CALL_DUMMY_BREAKPOINT_OFFSET to check
>         CALL_DUMMY_BREAKPOINT_OFFSET_P.
> 
>         * config/tm-sysv4.h: Made SKIP_TRAMPOLINE_CODE multiarch
>         compatible.
>        
>         * signals.c: Fixed so that the gdbserver could build it to use
>         target_signal_to_host & target_signal_from_host gdbserver was very
>         broken & had a severe fixme wrt signals.
> 
>         * gdbserver/Makefile.in: Made makefile go to parent directory for
>         source files (so as to build signal.c).
>         * gdbserver/low-linux.c: Added s390 32/64 bit support Fixed
>         assumption that PTRACE_XFER_TYPE was an int added
>         CANNOT_FETCH_REGISTER & CANNOT_STORE_REGISTER macros.  Fixed
>         fetch_inferior_registers etc. to work with s390 floating point
>         regs.
>         * gdbserver/server.c: Added target signal remapping FIXME.
>         * gdbserver/remote-utils: Likewise.
> 
>         And also:
>         * defs.h: When GDBSERVER undef GDB_MULTI_ARCH.
>         * gdbarch.c: Regenerate.
>        

Into the branch gdb_s390-2001-09-26-branch.  The actual files changed were:

M config.sub
M gdb/configure.host
M gdb/defs.h
M gdb/gdbarch.c
M gdb/gdbarch.sh
A gdb/s390-nat.c
A gdb/s390-tdep.c
M gdb/signals.c
M gdb/config/tm-sysv4.h
A gdb/config/s390/nm-linux.h
A gdb/config/s390/s390.mh
A gdb/config/s390/s390.mt
A gdb/config/s390/s390x.mt
A gdb/config/s390/tm-linux.h
A gdb/config/s390/tm-s390.h
A gdb/config/s390/xm-linux.h
M gdb/gdbserver/Makefile.in
M gdb/gdbserver/low-linux.c
M gdb/gdbserver/remote-utils.c
M gdb/gdbserver/server.c

The new s390 files will go straight onto 5.1 without change (and likely 
ditto to the trunk (perhaphs indented)).

I need to think about both gdbarch.sh and tm-sysv4.h.  Denis, can you 
expand?

Hopefully the top level changes can be abandoned and instead up-to-date 
versions of the affected files can simply be pulled in.

This leaves the gdbserver related changes: defs.h, signals.c, 
gdbserver/*.  Anyone want to look at this?

Andrew