Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: luisgpm@linux.vnet.ibm.com
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] Detecting and printing 128-bit long double values for GDB 	6.6
Date: Mon, 23 Apr 2007 22:43:00 -0000	[thread overview]
Message-ID: <200704232151.l3NLp9xY012977@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <1177352366.15414.28.camel@localhost> (message from Luis Machado 	on Mon, 23 Apr 2007 15:19:26 -0300)

> From: Luis Machado <luisgpm@linux.vnet.ibm.com>
> Date: Mon, 23 Apr 2007 15:19:26 -0300
> 
> Hi folks,
> 
> Attached is the patch previously written by Pete Carr for correcting the
> issue where GDB is unable to print the value of a 128-bit long double
> variable. This patch makes GDB recognize that data type and also makes
> it print the correct value with its full precision. I refreshed this
> patch for GDB 6.6, in case users of this version would like to use it.
> 
> A version of the patch for GDB HEAD is being worked on and will be
> submitted soon, since it requires some code changes due to a
> modification in the handling of Big endian/Little endian values.
> 
> Best regards,
> Luis

Some comments that you may want to take into account in the diff
you're working on:

> Index: gdb/rs6000-tdep.c
> ===================================================================
> --- gdb/rs6000-tdep.c.orig
> +++ gdb/rs6000-tdep.c
> @@ -3391,7 +3391,19 @@ rs6000_gdbarch_init (struct gdbarch_info
>    set_gdbarch_float_bit (gdbarch, 4 * TARGET_CHAR_BIT);
>    set_gdbarch_double_bit (gdbarch, 8 * TARGET_CHAR_BIT);
>    if (sysv_abi)
> -    set_gdbarch_long_double_bit (gdbarch, 16 * TARGET_CHAR_BIT);
> +    {
> +      int byte_order = gdbarch_byte_order (gdbarch);
> +
> +      if (byte_order == BFD_ENDIAN_BIG)
> +        set_gdbarch_long_double_format (gdbarch, &floatformat_ppc64_long_double_big);
> +      else if (byte_order == BFD_ENDIAN_LITTLE) 
> +        set_gdbarch_long_double_format (gdbarch, &floatformat_ppc64_long_double_little);
> +      else
> +        internal_error (__FILE__, __LINE__,
> +                      _("rs6000_gdbarch_init: "
> +                        "bad byte order"));
> +      set_gdbarch_long_double_bit (gdbarch, 16 * TARGET_CHAR_BIT);
> +    }
>    else
>      set_gdbarch_long_double_bit (gdbarch, 8 * TARGET_CHAR_BIT);
>    set_gdbarch_char_signed (gdbarch, 0);

This does not only change things for 64-bit powerpc, but also affects
32-bit powerpc.

> Index: libiberty/floatformat.c
> ===================================================================
> --- libiberty/floatformat.c.orig
> +++ libiberty/floatformat.c
> @@ -106,6 +106,25 @@ const struct floatformat floatformat_iee
>    floatformat_always_valid
>  };
>  
> +/* floatformats for ppc64 long double, big and little endian.           */
> +/* The layout is a pair of doubles. Don't use this description to pass  */
> +/* information to get_field(). The bit size is the important thing.     */

Please format your comments according to the GNU coding standards.

> Index: gdb/ppc-linux-tdep.c
> ===================================================================
> --- gdb/ppc-linux-tdep.c.orig
> +++ gdb/ppc-linux-tdep.c
> @@ -1036,7 +1036,9 @@ ppc_linux_init_abi (struct gdbarch_info 
>       Linux[sic] Standards Base says that programs that use 'long
>       double' on PPC GNU/Linux are non-conformant.  */
>    /* NOTE: cagney/2005-01-25: True for both 32- and 64-bit.  */
> +#if 0
>    set_gdbarch_long_double_bit (gdbarch, 8 * TARGET_CHAR_BIT);
> +#endif
>  
>    if (tdep->wordsize == 4)
>      {

Please don't #if 0 bits of code.  The code is either right or it is
wrong.  If it is wrong, it should be removed.  And in that case the
comment has to be changed too of course.


  reply	other threads:[~2007-04-23 21:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-23 18:19 Luis Machado
2007-04-23 22:43 ` Mark Kettenis [this message]
2007-04-24 18:03   ` Luis Machado
2007-04-23 23:18 ` Andreas Schwab

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=200704232151.l3NLp9xY012977@brahms.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --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