aboutsummaryrefslogtreecommitdiff
path: root/gdb/dwarf2read.c
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2019-03-14 13:58:58 +0000
committerAndrew Burgess <andrew.burgess@embecosm.com>2019-04-01 21:41:49 +0100
commit8bdc16587e26100282094c8eaa8e83180ba57afd (patch)
tree5e18b77acd219a53d4ac482fd56e060d05927964 /gdb/dwarf2read.c
parentc29705b71a8ec966478c0dc4712194a95291c6de (diff)
downloadgdb-8bdc16587e26100282094c8eaa8e83180ba57afd.zip
gdb-8bdc16587e26100282094c8eaa8e83180ba57afd.tar.gz
gdb-8bdc16587e26100282094c8eaa8e83180ba57afd.tar.bz2
gdb: Add $_cimag and $_creal internal functions
Add two new internal functions $_cimag and $_creal that extract the imaginary and real parts of a complex value. These internal functions can take a complex value of any type 'float complex', 'double complex', or 'long double complex' and return a suitable floating point value 'float', 'double', or 'long double'. So we can now do this: (gdb) p z1 $1 = 1.5 + 4.5 * I (gdb) p $_cimag (z1) $4 = 4.5 (gdb) p $_creal (z1) $4 = 1.5 The components of a complex value are not strictly named types in DWARF, as the complex type is itself the base type. However, once we are able to extract the components it makes sense to be able to ask what the type of these components is and get a sensible answer back, rather than the error we would currently get. Currently GDB says: (gdb) ptype z1 type = complex double (gdb) p $_cimag (z1) $4 = 4.5 (gdb) ptype $ type = <invalid type code 9> With the changes in dwarf2read.c, GDB now says: (gdb) ptype z1 type = complex double (gdb) p $_cimag (z1) $4 = 4.5 (gdb) ptype $ type = double Which seems to make more sense. gdb/ChangeLog: * NEWS: Mention new internal functions. * dwarf2read.c (dwarf2_init_complex_target_type): New function. (read_base_type): Use dwarf2_init_complex_target_type. * value.c (creal_internal_fn): New function. (cimag_internal_fn): New function. (_initialize_values): Register new internal functions. gdb/doc/ChangeLog: * gdb.texinfo (Convenience Funs): Document '$_creal' and '$_cimag'. gdb/testsuite/ChangeLog: * gdb.base/complex-parts.c: New file. * gdb.base/complex-parts.exp: New file.
Diffstat (limited to 'gdb/dwarf2read.c')
-rw-r--r--gdb/dwarf2read.c36
1 files changed, 35 insertions, 1 deletions
diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index a5e953b..8881a1e 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -17530,6 +17530,40 @@ dwarf2_init_integer_type (struct dwarf2_cu *cu, struct objfile *objfile,
return type;
}
+/* Initialise and return a floating point type of size BITS suitable for
+ use as a component of a complex number. The NAME_HINT is passed through
+ when initialising the floating point type and is the name of the complex
+ type.
+
+ As DWARF doesn't currently provide an explicit name for the components
+ of a complex number, but it can be helpful to have these components
+ named, we try to select a suitable name based on the size of the
+ component. */
+static struct type *
+dwarf2_init_complex_target_type (struct dwarf2_cu *cu,
+ struct objfile *objfile,
+ int bits, const char *name_hint)
+{
+ gdbarch *gdbarch = get_objfile_arch (objfile);
+ struct type *tt = nullptr;
+
+ switch (bits)
+ {
+ case 32:
+ tt = builtin_type (gdbarch)->builtin_float;
+ break;
+ case 64:
+ tt = builtin_type (gdbarch)->builtin_double;
+ break;
+ case 128:
+ tt = builtin_type (gdbarch)->builtin_long_double;
+ break;
+ }
+
+ const char *name = (tt == nullptr) ? nullptr : TYPE_NAME (tt);
+ return dwarf2_init_float_type (objfile, bits, name, name_hint);
+}
+
/* Find a representation of a given base type and install
it in the TYPE field of the die. */
@@ -17569,7 +17603,7 @@ read_base_type (struct die_info *die, struct dwarf2_cu *cu)
type = init_boolean_type (objfile, bits, 1, name);
break;
case DW_ATE_complex_float:
- type = dwarf2_init_float_type (objfile, bits / 2, NULL, name);
+ type = dwarf2_init_complex_target_type (cu, objfile, bits / 2, name);
type = init_complex_type (objfile, name, type);
break;
case DW_ATE_decimal_float: