[PATCH ver 2] PowerPC: fix _Float128 type output string

[Carl Love]

Tom:

On Fri, 2023-04-14 at 07:44 -0600, Tom Tromey wrote:
> > > > > > "Carl" == Carl Love via Gdb-patches <
> > > > > > gdb-patches@sourceware.org> writes:
> > > However, doesn't copy_type also copy the TYPE_FLOATFORMAT field?
> > > So where would this get reset?
> 
> Carl> the GCC-generated dwarf info including the hack provides
> Carl> the following two type records:
> 
> Carl> 1) name: _Float128
> Carl>    type: base floating-point type (TYPE_CODE_FLT)
> Carl>      size: 16
> Carl>      format: floatformats_ieee_quad
> 
> Carl> and
> 
> Carl> 2) name: "long double"
> Carl>    type: typedef (TYPE_CODE_TYPEDEF)
> Carl>      target-type: _Float128 (i.e. type 1) above)
> 
> Carl> What the patch does is to keep 1) as-is, and replace 2) by
> 
> Carl> 2') name: "long double"
> Carl>     type: base floating-point type (TYPE_CODE_FLT)
> Carl>       size: 16
> Carl>       format: floatformats_ieee_quad
> 
> Carl> where the name is taken from 2), and the rest of the
> Carl> record is taken from 1). 
> 
> Sorry for going in circles on this, but I still don't really get it.
> 
> From what I can see, the difference between (2) and (2') is just that
> one is a typedef and one is not.  Where does this matter?
> 
OK, I think I know what you are not getting.  

When the user wants to know the type of a variable, it gets the name
from the base type.  For example in the test program
gdb/testsuite/gdb.base/whatis-ptype-typedefs.c, we have the
declaration:

   typedef long double long_double_typedef;

On PowerPC, if GCC is using IEEE float 128-bit for the long double
format, the test case uses the ptype command to get the type of the
variable long_double_typedef, i.e.

   ptype v_long_double_typedef2

without the patch, GDB returns the base type name, in this case GDB
prints:

   type = _Float128
   
Note the type the user specified of "long double" and the GDB test case
is expecting the result to be "long double".  This results in the 74
test failures on PowerPC with when GCC uses IEEE float 128-bit. 

The "_Float128" is printed because the "long double" is typedef
pointing at the base type "_Float 128".  GDB tells the user the type of
the variable is something that the user didn't specify which is very
confusing to them, and to the testcase.  This is where the GCC "hack"
for identifying the "long double" as an IEEE 128-bit float value rather
than the IBM 128-bit float value is not transparent to GDB.

The GCC hack created this typedef for "long double", which should never
be a typedef since it is a base type in C.  The patch basically undoes
the GCC hack by making the type for "long double" a proper base type
again using the info from the _Float128 base type and the correct name
"long double".  Now, the GDB ptype command prints the proper type name
and the rest of the type info is there that GDB needs.  The comment in
gdb/gdbarch_components.py mentions that with the patch the proper name
is printed, but yea I can see where that wasn't completely obvious to
you.

Does that help?

                               Carl