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

[Ulrich Weigand <Ulrich.Weigand@de.ibm.com>]

Tom Tromey <tom@tromey.com> wrote:

>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?

This matters as it changes how GDB prints the type.   If your source
code has e.g. a variable definition like
  long double x;
and you do e.g. "ptype x" in GDB, you'd expect to see "long double".

However, with the GCC hack typedef in place, you actually see
"_Float128" instead.  This not only confuses the user, it actually
causes a bunch of GDB test suite failures currently.

To summarize the set of problems that were leading up to this
scenario:

1) The ppc64le platform is currently in the process of switching
   the format of the "long double" type from the special IBM
   double-double to the standard IEEE 128-bit format.  Because
   of this, "long double" may currently refer to either of
   the two formats, depending on compiler version and options.
   For GDB to handle this correctly, the compiler therefore needs
   some way of informing GDB of the format actually used in any
   specific executable.

2) Since both types are 16-byte floating-point types, there is
   no method in the current DWARF standard to distinguish between
   them.  Therefore, GCC developers have added a hack that no
   longer emits "long double" as a DWARF base floating-point
   type, but rather emits "long double" as if it were defined
   as a typedef (with "_Float128" as target type).  [This is done
   only in those configurations where "long double" actually uses
   the IEEE format, otherwise "long double" remains a base type.]

3) GDB already recognizes "_Float128" (by name) and knows it
   always uses the IEEE 128-bit format, so it will automatically
   use the same format now for "long double" as well, if that
   typedef hack is present.  This makes GDB handle that type
   correctly - for the most part.

4) The exception is when printing the *name* of type, in which
   case we get the name "_Float128" showing up unexpectedly,
   as discussed above.

5) Carl's patch now adds a hack to GDB to "cancel out" the GCC
   hack by removing that typedef hack again, and defining
   "long double" as a base type (instead of a typedef) again.
   Note that since this base type inherits the format from
   the typedef hack's target type (_Float128), the GCC hack
   still fulfils its purpose of informing GDB of the proper
   format to use for "long double" - but now also type name
   printing works correctly.

I agree this is all a bit awkward, but given the GCC hack is
already out in the field, I don't really any better option to
handle this in GDB.

All this could probably go away once:
- there's a new DWARF format (or extension) that allows providing
  multiple floating-point base types with the same size but using
  different formats;
and
- there are no executables left in the field that still have the
  GCC typedef hack in their debug info.

Bye,
Ulrich