diff mbox

New FAIL on gdb.base/complex-parts.exp - unix/-m32 (was: Re: [PATCH 1/8] gdb: Add $_cimag and $_creal internal functions)

Message ID 20190413000202.GF2737@embecosm.com
State New, archived
Headers

Commit Message

Andrew Burgess April 13, 2019, 12:02 a.m. UTC 
  * Sergio Durigan Junior <sergiodj@redhat.com> [2019-04-12 16:23:57 -0400]:

> On Monday, March 18 2019, Andrew Burgess wrote:
> 
> > Add two new internal functions $_cimag and $_creal that extract the
> > imaginary and real parts of a complex value.
> [...]
> 
> Hi Andrew,
> 
> The new testcase gdb.base/complex-parts.exp has one new FAIL when
> testing x86_64 GDB against unix/-m32.  I.e.:
> 
>   make check-gdb TESTS=gdb.base/complex-parts.exp RUNTESTFLAGS='--target_board unix/-m32'
> 
> Here's what I'm seeing:
> 
>   ptype $
>   type = <invalid type code 9>
>   (gdb) FAIL: gdb.base/complex-parts.exp: ptype $
>   ...
>   ptype $
>   type = <invalid type code 9>
>   (gdb) FAIL: gdb.base/complex-parts.exp: ptype $
> 
> The BuildBot run:
> 
>   https://gdb-build.sergiodj.net/builders/Fedora-x86_64-m32/builds/12210
> 
> The logs:
> 
>   https://gdb-build.sergiodj.net/results/Fedora-x86_64-m32/8b/8bdc16587e26100282094c8eaa8e83180ba57afd/
> 
> Let me know if you need help investigating this.

Thanks for pointing this out.

I've pushed the patch below to resolve this issue.

Thanks,
Andrew

--

[PATCH] gdb: Fix failure in gdb.base/complex-parts.exp for x86-32

The x86-32 ABI specifies 96-bit long double, this was causing a
failure on the test gdb.base/complex-parts.exp.

The problem is that GDB tries to find a builtin floating point type of
the correct size in order to reuse the name of that type as the name
for the components of the complex type being built.

Previously GDB was only aware of floating point types sized 32, 64, or
128 bits.  This patch teaches GDB how to handle 96 bit floating point
type.

gdb/ChangeLog:

	* dwarf2read.c (dwarf2_init_complex_target_type): Handle complex
	target types of size 96-bits, add some additional comments, and
	check that the builtin type we found was the correct size.
---
 gdb/ChangeLog    |  6 ++++++
 gdb/dwarf2read.c | 10 ++++++++++
 2 files changed, 16 insertions(+)
diff mbox

Patch

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index b718192cb12..0873028e438 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -17546,6 +17546,9 @@  dwarf2_init_complex_target_type (struct dwarf2_cu *cu,
   gdbarch *gdbarch = get_objfile_arch (objfile);
   struct type *tt = nullptr;
 
+  /* Try to find a suitable floating point builtin type of size BITS.
+     We're going to use the name of this type as the name for the complex
+     target type that we are about to create.  */
   switch (bits)
     {
     case 32:
@@ -17554,11 +17557,18 @@  dwarf2_init_complex_target_type (struct dwarf2_cu *cu,
     case 64:
       tt = builtin_type (gdbarch)->builtin_double;
       break;
+    case 96:	/* The x86-32 ABI specifies 96-bit long double.  */
     case 128:
       tt = builtin_type (gdbarch)->builtin_long_double;
       break;
     }
 
+  /* If the type we found doesn't match the size we were looking for, then
+     pretend we didn't find a type at all, the complex target type we
+     create will then be nameless.  */
+  if (TYPE_LENGTH (tt) * TARGET_CHAR_BIT != bits)
+    tt = nullptr;
+
   const char *name = (tt == nullptr) ? nullptr : TYPE_NAME (tt);
   return dwarf2_init_float_type (objfile, bits, name, name_hint);
 }