public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Carl Love via Gdb-patches <gdb-patches@sourceware.org>
Cc: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	 Carl Love <cel@us.ibm.com>, Kevin Buettner <kevinb@redhat.com>
Subject: Re: [PATCH ver 2] PowerPC: fix _Float128 type output string
Date: Thu, 13 Apr 2023 08:18:59 -0600	[thread overview]
Message-ID: <87fs936f1o.fsf@tromey.com> (raw)
In-Reply-To: <1b5d214a6208c422963e58c27c98f81af9601628.camel@us.ibm.com> (Carl Love via Gdb-patches's message of "Mon, 10 Apr 2023 09:01:21 -0700")

>>>>> "Carl" == Carl Love via Gdb-patches <gdb-patches@sourceware.org> writes:

Carl> PowerPC supports two 128-bit floating point formats, the IBM long double
Carl> and IEEE 128-bit float.  The issue is the DWARF information does not
Carl> distinguish between the two.  There have been proposals of how to extend
Carl> the DWARF information as discussed in
Carl> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
Carl> but has not been fully implemented.

Could it be?  I didn't read the issue but it's often better to put in
the effort to fix the problem in the compiler.  Normally once these
workarounds go into gdb, they can never be removed.

Carl> This patch fixes 74 regression test failures in
Carl> gdb.base/whatis-ptype-typedefs.exp on PowerPC with IEEE float 128 as the
Carl> default on GCC.  It fixes one regression test failure in
Carl> gdb.base/complex-parts.exp.

I don't really understand how this patch works.

It took me a while to understand that maybe the issue is that the
association between a gdb type and a float format is done by name and
size, and because this is a typedef, the association is done instead by
the underlying type -- which is then wrong.

However, doesn't copy_type also copy the TYPE_FLOATFORMAT field?
So where would this get reset?

Or maybe this isn't the problem at all, but then I don't understand what
it would be.

Carl> +# The DWARF info currently does not distinquish between IEEE 128-bit floating
Carl> +# point values and the IBM 128-bit floating point format.  GCC has an internal
Carl> +# hack that uses the _Float128 base typdef for IEEE 128-bit float values.  The
Carl> +# following method is used to "fix" the long double typedef so the _Float128
Carl> +# name is not printed.
Carl> +Function(
Carl> +    comment="""
Carl> +Return true if the typedef record needs to be replaced.".
Carl> +
Carl> +Return 0 by default""",

I think the comment field could be reworded to be more clear.
I guess the idea is that some typedefs are replaced by their target
type, but given the typedef's name.

Carl> +bool
Carl> +linux_dwarf2_omit_typedef_p (struct type *target_type,
Carl> +			     const char *producer, const char *name)

I think this can be 'static'.

Tom

  reply	other threads:[~2023-04-13 14:19 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 [this message]
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
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=87fs936f1o.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=cel@us.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=kevinb@redhat.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).