OpenE2K/binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

S390: Fix crash when remote tdesc doesn't define vec128

Browse Source 
I've encountered a GDB crash when trying to read registers from a remote
stub that provided a target.xml with vector registers, but without the
'vec128' data type.  The crash is caused by NULL register type entries for
the "concatenated" pseudo-registers v0-v15.  These NULL entries are
introduced by the logic in s390_pseudo_register_type(), where the tdesc
type 'vec128' is returned unconditionally -- even if it doesn't exist (is
NULL).

The fixed logic for determining a "concatenated" vector register's type
now returns the type of the raw register v16 instead.  This also makes
sure that all vector register have the same type.

gdb/ChangeLog:

	* s390-tdep.c (s390_pseudo_register_type): For v0-v15 don't yield
	the possibly non-existent tdesc type 'vec128', but the type of raw
	register v16 instead.
This commit is contained in:
Andreas Arnez 2018-10-19 14:05:08 +02:00
parent ba543ca5af
commit 0667c50682
2 changed files with 8 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
gdb/ChangeLog
View File

@ -1,3 +1,9 @@
2018-10-19 Andreas Arnez <arnez@linux.ibm.com>
* s390-tdep.c (s390_pseudo_register_type): For v0-v15 don't yield
the possibly non-existent tdesc type 'vec128', but the type of raw
register v16 instead.
2018-10-19 Gary Benson <gbenson@redhat.com>
* cli/cli-interp.c (cli_interp::~cli_interp): New function.

3
gdb/s390-tdep.c
View File

@ -1275,8 +1275,9 @@ s390_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
if (regnum_is_gpr_full (tdep, regnum))
return builtin_type (gdbarch)->builtin_uint64;
/* For the "concatenated" vector registers use the same type as v16. */
if (regnum_is_vxr_full (tdep, regnum))
return tdesc_find_type (gdbarch, "vec128");
return tdesc_register_type (gdbarch, S390_V16_REGNUM);
internal_error (__FILE__, __LINE__, _("invalid regnum"));
}