public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Carl Love <cel@us.ibm.com>
To: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Cc: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	Kevin Buettner <kevinb@redhat.com>,
	cel@us.ibm.com
Subject: RE: [PATCH ver 2] PowerPC: fix _Float128 type output string
Date: Fri, 14 Apr 2023 08:35:20 -0700	[thread overview]
Message-ID: <0039ecebd46d4638c1f93a5e7964d4bc54cfae85.camel@us.ibm.com> (raw)
In-Reply-To: <87wn2e4lys.fsf@tromey.com>

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 


  reply	other threads:[~2023-04-14 15:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-05 15:28 [PATCH] " Carl Love
2023-04-05 20:18 ` Carl Love
2023-04-07 21:51   ` Kevin Buettner
2023-04-10 15:43     ` Carl Love
2023-04-10 15:46   ` [PATCH ver 2] " Carl Love
2023-04-10 16:01 ` Carl Love
2023-04-13 14:18   ` Tom Tromey
2023-04-13 16:13     ` Carl Love
2023-04-13 16:35       ` Carl Love
2023-04-13 17:12         ` Tom Tromey
2023-04-13 22:08           ` Carl Love
2023-04-17 15:45             ` [PATCH ver 3] " Carl Love
2023-04-18 10:18               ` Ulrich Weigand
2023-04-14 13:44       ` [PATCH ver 2] " Tom Tromey
2023-04-14 15:35         ` Carl Love [this message]
2023-04-17 10:26         ` Ulrich Weigand
2023-04-17 20:17           ` Tom Tromey
2023-04-18 10:17             ` Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0039ecebd46d4638c1f93a5e7964d4bc54cfae85.camel@us.ibm.com \
    --to=cel@us.ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=kevinb@redhat.com \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).