Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: drow@false.org (Daniel Jacobowitz)
Cc: luisgpm@linux.vnet.ibm.com (Luis Machado),
	        gdb-patches@sourceware.org (gdb-patches ml)
Subject: Re: [RFC] Detecting and printing 128-bit long double values for PPC
Date: Sun, 06 May 2007 21:36:00 -0000	[thread overview]
Message-ID: <200705062136.l46La00Q029476@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20070430135259.GA7430@caradoc.them.org> from "Daniel Jacobowitz" at Apr 30, 2007 09:52:59 AM

Daniel Jacobowitz wrote:
> On Mon, Apr 30, 2007 at 10:44:20AM -0300, Luis Machado wrote:
> > > This is "the ABI-defined long double type", which GDB distinguishes
> > > from "the debug info describing long double".  I suppose you could
> > > come up with a way to distinguish binaries based on what their debug
> > > info has to say about it, if it mentions long double anywhere.

I wasn't aware of that.  I now see that DWARF-2 does provide information
about all "fundamental data types" used by the program; this makes things
a lot easier ...

> > The idea could be that in case a different type is defined in the debug
> > info than it's in the DWARF info, GDB would stick with what the debug
> > info says instead.
> > 
> > But then we would rely on debugging info for performing type
> > identification. What about debugging running processes that do not have
> > explicit debug info?
> 
> That's exactly the problem.  For the future, I'll try to solve this
> using binary tagging.  But for now, I think a user-settable option may
> be the best we can do.  Does anyone see a better way?

Why do we care about the case of programs without debug info?  If we
don't know of any entity of type "long double" because we don't have
debug info, we don't care what that type is either ...

I guess the user could do explicit type casts on the GDB command line,
but then they could just as well explicitly use "double" instead of
"long double" -- that's no more effort than employing a user-settable
option ...

> It may be OK to default to 128-bit long double, since 64-bit long
> double "more or less" works anyway.

Under the circumstances, I'd argue we should just change the built-in
type to 128-bit, and make sure that binaries with a DWARF-2 reported
"long double" fundamental type of 64-bit still use the proper floating
point format info for that type.

Anything I'm missing here?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


  reply	other threads:[~2007-05-06 21:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-28 14:08 Luis Machado
2007-04-28 16:19 ` Daniel Jacobowitz
2007-04-28 16:27   ` Ulrich Weigand
2007-04-28 16:49     ` Daniel Jacobowitz
2007-04-28 23:47       ` Luis Machado
2007-04-30 12:28         ` Ulrich Weigand
2007-04-30 12:41           ` Daniel Jacobowitz
2007-04-30 13:15             ` Luis Machado
2007-04-30 13:19               ` Daniel Jacobowitz
2007-04-30 13:51                 ` Luis Machado
2007-04-30 13:53                   ` Luis Machado
2007-04-30 14:12                   ` Daniel Jacobowitz
2007-05-06 21:36                     ` Ulrich Weigand [this message]
2007-05-06 22:17                       ` Daniel Jacobowitz
2007-08-31 18:15                         ` Luis Machado
2007-08-31 18:27                           ` Joseph S. Myers
2007-04-30 18:03                 ` Luis Machado
2007-04-30 13:08           ` Luis Machado

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=200705062136.l46La00Q029476@d12av02.megacenter.de.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=luisgpm@linux.vnet.ibm.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