From: Eli Zaretskii <eliz@gnu.org>
To: luisgpm@linux.vnet.ibm.com
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] printf support for DFP values
Date: Sat, 27 Oct 2007 12:05:00 -0000 [thread overview]
Message-ID: <ubqaksyin.fsf@gnu.org> (raw)
In-Reply-To: <1193449497.6950.22.camel@localhost> (message from Luis Machado on Fri, 26 Oct 2007 22:44:57 -0300)
> From: Luis Machado <luisgpm@linux.vnet.ibm.com>
> Date: Fri, 26 Oct 2007 22:44:57 -0300
>
> GDB's printf command currently does not support printing of DFP values
> (Decimal32, Decimal64 and Decimal128). The following patch proposes to
> fix that by allowing GDB's printf command to deal with those numbers.
Thanks.
> Native DFP printing support with printf is not yet ready, but it should
> be in some time eventually. Due to this, i'm testing for native printf
> support for DFP in the configure script and setting a constant to
> reflect the result (PRINTF_HAS_DECFLOAT). Based on that GDB has two ways
> of dealing with the problem:
>
> 1 - If we have native support (and thus PRINTF_HAS_DECFLOAT is set), we
> just send the DFP value straight to the standard printing routine with
> its format specifiers (printf_filtered).
>
> 2 - If there's currently no support, we stick with converting the DFP
> values to strings and using string format specifiers to print them. This
> should make things flexible enough for both systems, one that has native
> printf support for DFP and one that doesn't.
>
> I'd appreciate comments on this one.
If we can implement DFP printing in GDB, why should we also check for
native DFP support and use that if available? Are there any
advantages in the native DFP printing, and if so, what are they?
Also, if this patch is accepted, please submit also a suitable patch
for the manual (doc/gdb.texinfo), where we describe the format
conversions supported by the `printf' command (node "Output").
A few questions/comments to the patch itself:
> - double_arg, long_double_arg
> + double_arg, long_double_arg, decfloat_arg
You are using decfloat_arg unconditionally, but I don't see it defined
anywhere in today's CVS. Am I missing something?
> + /* Replace %H, %D and %DD for %s's. */
Did you mean "Replace ... _with_ %s's"?
next prev parent reply other threads:[~2007-10-27 9:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-27 6:25 Luis Machado
2007-10-27 12:05 ` Eli Zaretskii [this message]
2007-10-29 15:03 ` Luis Machado
2007-10-29 20:12 ` Eli Zaretskii
2007-10-29 20:19 ` Daniel Jacobowitz
2007-10-30 4:20 ` Eli Zaretskii
2007-10-30 4:39 ` Eli Zaretskii
2007-10-30 18:19 ` Luis Machado
2007-10-30 20:58 ` Eli Zaretskii
2007-11-01 1:18 ` Luis Machado
2007-11-01 4:11 ` Eli Zaretskii
2007-11-01 10:21 ` Andreas Schwab
2007-11-01 12:02 ` Luis Machado
2007-11-02 12:05 ` Eli Zaretskii
2007-11-01 15:34 ` Daniel Jacobowitz
2007-11-01 16:00 ` Luis Machado
2007-11-02 12:07 ` Eli Zaretskii
2007-11-05 11:35 ` 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=ubqaksyin.fsf@gnu.org \
--to=eliz@gnu.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