diff options
author | Andrew Burgess <andrew.burgess@embecosm.com> | 2019-03-14 13:58:58 +0000 |
---|---|---|
committer | Andrew Burgess <andrew.burgess@embecosm.com> | 2019-04-01 21:41:49 +0100 |
commit | 8bdc16587e26100282094c8eaa8e83180ba57afd (patch) | |
tree | 5e18b77acd219a53d4ac482fd56e060d05927964 /gdb/dwarf2read.c | |
parent | c29705b71a8ec966478c0dc4712194a95291c6de (diff) | |
download | gdb-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.c | 36 |
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: |