aboutsummaryrefslogtreecommitdiff
path: root/gdb/stack.c
diff options
context:
space:
mode:
authorAndreas Arnez <arnez@linux.ibm.com>2018-10-19 14:05:08 +0200
committerAndreas Arnez <arnez@linux.ibm.com>2018-10-19 14:05:08 +0200
commit0667c506823489f2fab1938d3fc8ee27f8a7c651 (patch)
treee89f9d59ed4f0cb4e14e6e01f808ef3a55923f6b /gdb/stack.c
parentba543ca5afafed5bda2db52e8f424f20ff605173 (diff)
downloadgdb-0667c506823489f2fab1938d3fc8ee27f8a7c651.zip
gdb-0667c506823489f2fab1938d3fc8ee27f8a7c651.tar.gz
gdb-0667c506823489f2fab1938d3fc8ee27f8a7c651.tar.bz2
S390: Fix crash when remote tdesc doesn't define vec128
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.
Diffstat (limited to 'gdb/stack.c')
0 files changed, 0 insertions, 0 deletions