From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Denis Joseph Barrow Cc: gdb-patches@sourceware.cygnus.com Subject: Re: gdb & gdbserver for s390 31 & 64 bit Date: Wed, 26 Sep 2001 18:26:00 -0000 Message-id: <3BB2802C.9020700@cygnus.com> References: X-SW-Source: 2001-09/msg00377.html 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 > > From 2001-08-22 D.J. Barrow : > * config.sub: Added S/390 31 & 64 bit target. > > 2001-09-26 Andrew Cagney > > From 2001-07-09 D.J. Barrow : > > * 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