aboutsummaryrefslogtreecommitdiff
path: root/gas/doc
diff options
context:
space:
mode:
authorPhilipp Rudo <prudo@linux.vnet.ibm.com>2018-01-23 13:37:43 +0100
committerAndreas Arnez <arnez@linux.vnet.ibm.com>2018-01-23 13:37:43 +0100
commit7042632bf7976d29889ba89fe4867654c5f38e2d (patch)
tree73313b367a98aaab7aa0f43048ff06070ff7a892 /gas/doc
parent650f5e137006fb7aea98e33d2ca9c6ac6712334c (diff)
downloadgdb-7042632bf7976d29889ba89fe4867654c5f38e2d.zip
gdb-7042632bf7976d29889ba89fe4867654c5f38e2d.tar.gz
gdb-7042632bf7976d29889ba89fe4867654c5f38e2d.tar.bz2
s390: Hook s390 into OSABI mechanism
Do what the title says and distinguish between 31- and 64-bit systems. The goal is to init the OSABI as late as possible in gdbarch_init so the OSABI has the chance to overwrite the defaults. There are two pitfalls to be aware of: First, the dwarf2 unwinder must be appended before the OSABI is initialized. Otherwise the OS could add a default unwinder which always takes control before the dwarf unwinder even gets a chance. Second, tdesc_use_registers has to be handled with extra care. It sets several gdbarch hooks, especially gdbarch_register_name, which has to be overwritten again after the call. Furthermore it deletes the tdesc_data without checking. Therefore there must not be a call to tdesc_data_cleanup afterwards or GDB will crash with a double free. gdb/ChangeLog: * s390-linux-tdep.c (osabi.h): New include. (s390_linux_init_abi_31, s390_linux_init_abi_64) (s390_linux_init_abi_any): New functions. (s390_gdbarch_init, _initialize_s390_tdep): Adjust.
Diffstat (limited to 'gas/doc')
0 files changed, 0 insertions, 0 deletions