gdbserver/s390: Enable high GPRs, VX, TDB with 31-bit gdbserver.

  Currently, 31-bit gdbserver doesn't support collecting/supplying high
GPRs, VX registers, and TDB data.  This is not much of a problem now,
since machines that have them usually have a 64-bit gdbserver that can
be used to debug 31-bit targets just fine.  However, with fast
tracepoints, it's not possible to use a 64-bit gdbserver with a 31-bit
IPA (and thus a 31-bit target), so 31-bit gdbserver has to be used
for 31-bit targets.  Thus, this patch is needed to allow collecting
high GPRs and VX registers on 31-bit targets via fast tracepoints.

gdb/gdbserver/ChangeLog:

	* linux-s390-low.c (s390_num_regs_3264): Define on 31-bit too.
	(s390_regmap_3264) [!__s390x__]: New global.
	(s390_collect_ptrace_register): Skip map entries containing -1.
	(s390_supply_ptrace_register): Ditto.
	(s390_fill_gprs_high): New function.
	(s390_store_gprs_high): New function.
	(s390_regsets): Add NT_S390_HIGH_GPRS.
	(s390_get_hwcap): Enable on 31-bit.
	(have_hwcap_s390_high_gprs): Enable on 31-bit.
	(s390_arch_setup): Enable detection of high GPRs, TDB, VX on 31-bit.
	Detect NT_S390_HIGH_GPRS.
	(s390_usrregs_info_3264): Enable on 31-bit.
	(s390_regs_info): Enable regs_info_3264 on 31-bit.
	(initialize_low_arch): Initialize s390_regsets_info_3264 on 31-bit.
---
As mentioned in the s390 fast tracepoint thread, here comes a patch for
proper high GPR support (and VX+TDB while we're at it) in 31-bit
gdbserver.  It's mostly removing ifdefs for __s390x__ - the only
nontrivial part is the new regmap (with -1s for $rXh since they are not
in the basic register set), and the new regset.

Tests have been run (RHEL 7.2, configured for s390-ibm-linux-gnu on a 64-bit
kernel)), and it's a mixed bag.  A few new failures are present:

native-gdbserver: gdb.base/store.exp: up struct 1 u; print new u, expecting {s = \{1}}
native-gdbserver: gdb.base/store.exp: up struct 1 u; set u to s_1
native-gdbserver: gdb.base/store.exp: up struct 2 u; print new u, expecting {s = \{1, 2}}
native-gdbserver: gdb.base/store.exp: up struct 2 u; set u to s_2
native-gdbserver: gdb.base/store.exp: upvar charest l; print new l, expecting 4 ..004.
native-gdbserver: gdb.base/store.exp: upvar charest l; set l to 4
native-gdbserver: gdb.base/store.exp: upvar int l; print new l, expecting 4
native-gdbserver: gdb.base/store.exp: upvar int l; set l to 4
native-gdbserver: gdb.base/store.exp: upvar long l; print new l, expecting 4
native-gdbserver: gdb.base/store.exp: upvar long l; set l to 4
native-gdbserver: gdb.base/store.exp: upvar longest l; print new l, expecting 4
native-gdbserver: gdb.base/store.exp: upvar longest l; set l to 4
native-gdbserver: gdb.base/store.exp: upvar short l; print new l, expecting 4
native-gdbserver: gdb.base/store.exp: upvar short l; set l to 4

However, these failures are already present on 64-bit gdbserver with
-m31 target, so they're not really new.  On the other hand, if -mzarch
is included in CFLAGS, this patch fixes a few failures:

native-gdbserver: gdb.base/gdb1090.exp: print s24
native-gdbserver: gdb.base/store.exp: up struct 4 u; print old u, expecting {s = \{0, 0, 0, 0}}
native-gdbserver: gdb.base/store.exp: var longest l; print old l, expecting -1
native-gdbserver: gdb.base/store.exp: var struct 4 u; print old u, expecting {s = \{0, 0, 0, 0}}

So, I suppose we should look into the store.exp failures, there's a bug
in there somewhere...

 gdb/gdbserver/ChangeLog        |  18 +++++++
 gdb/gdbserver/linux-s390-low.c | 105 +++++++++++++++++++++++++++++++----------
 2 files changed, 97 insertions(+), 26 deletions(-)

gdbserver/s390: Enable high GPRs, VX, TDB with 31-bit gdbserver.

Commit Message

Comments

Patch