Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jeff Johnston <jjohnstn@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted
Date: Fri, 12 Dec 2003 20:36:00 -0000	[thread overview]
Message-ID: <3FDA26B1.6010704@redhat.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

There's some code in print_scalar_formatted() I would like to remove.  
It tests if the sizeof the type of the value being printed is greater 
than the sizeof of LONGEST and if so, it may attempt to use 
extract_unsigned_integer().  If that fails, it prints out the value in hex.

There a number of problems with this.  First and foremost is the fact 
that it is comparing the sizeof with the host's LONGEST type, not the 
target.  The second problem is that extract_unsigned_integer() does the 
same size test and returns failure so the call is pointless.  The third 
problem is that this code creates an inconsistency in how doubles/floats 
are treated in comparison to long double.   All  three of these types 
are capable of storing a value greater than  that which can be contained 
in a LONGEST.  At present, floats and possibly doubles will pass the 
size test and end up calling unpack_long().   True long double doesn't 
pass the test and ends up printing in hex.  This problem causes a number 
of new errors on ia64 with the latest changes to structs.exp.  The new 
testcase uses p/c to print out various types and is not ready for the 
hex version of the long double value being printed out.

To remedy the problem, I have removed the code.  I don't think it is 
particularly helpful.  I think if the user asks for an integral format, 
then they should be prepared to take what that choice entails when 
printing a float input. 

With this change, the new failures for the ia64 testsuite go away (no 
regressions).

Comments?

-- Jeff J.

2003-12-12  Jeff Johnston  <jjohnstn@redhat.com>

        * printcmd.c (print_scalar_formatted): Do not check for sizeof
        type being greater than sizeof of host's LONGEST.  Always use
        unpack_long() unless format 'f' chosen.


[-- Attachment #2: printcmd.patch --]
[-- Type: text/plain, Size: 1712 bytes --]

Index: printcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/printcmd.c,v
retrieving revision 1.69
diff -u -p -r1.69 printcmd.c
--- printcmd.c	21 Sep 2003 01:26:45 -0000	1.69
+++ printcmd.c	12 Dec 2003 20:16:16 -0000
@@ -346,44 +346,7 @@ print_scalar_formatted (void *valaddr, s
   LONGEST val_long;
   unsigned int len = TYPE_LENGTH (type);
 
-  if (len > sizeof (LONGEST)
-      && (format == 't'
-	  || format == 'c'
-	  || format == 'o'
-	  || format == 'u'
-	  || format == 'd'
-	  || format == 'x'))
-    {
-      if (!TYPE_UNSIGNED (type)
-	  || !extract_long_unsigned_integer (valaddr, len, &val_long))
-	{
-	  /* We can't print it normally, but we can print it in hex.
-	     Printing it in the wrong radix is more useful than saying
-	     "use /x, you dummy".  */
-	  /* FIXME:  we could also do octal or binary if that was the
-	     desired format.  */
-	  /* FIXME:  we should be using the size field to give us a
-	     minimum field width to print.  */
-
-	  if (format == 'o')
-	    print_octal_chars (stream, valaddr, len);
-	  else if (format == 'd')
-	    print_decimal_chars (stream, valaddr, len);
-	  else if (format == 't')
-	    print_binary_chars (stream, valaddr, len);
-	  else
-	    /* replace with call to print_hex_chars? Looks
-	       like val_print_type_code_int is redoing
-	       work.  - edie */
-
-	    val_print_type_code_int (type, valaddr, stream);
-
-	  return;
-	}
-
-      /* If we get here, extract_long_unsigned_integer set val_long.  */
-    }
-  else if (format != 'f')
+  if (format != 'f')
     val_long = unpack_long (type, valaddr);
 
   /* If the value is a pointer, and pointers and addresses are not the

             reply	other threads:[~2003-12-12 20:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-12 20:36 Jeff Johnston [this message]
2003-12-12 22:17 ` Kevin Buettner
2003-12-12 23:05   ` Daniel Jacobowitz
2003-12-13  0:55   ` J. Johnston
2004-01-19 22:23     ` J. Johnston
2004-01-19 22:57       ` Andrew Cagney
2004-01-19 23:18         ` Daniel Jacobowitz
2004-01-19 23:27           ` Kevin Buettner
2004-01-20  0:41           ` Andrew Cagney
2004-01-20  1:22             ` Daniel Jacobowitz
     [not found]               ` <400C8CC0.3040706@gnu.org>
2004-01-20  5:48                 ` Daniel Jacobowitz
2004-01-20  6:55                   ` Eli Zaretskii
2004-01-20 14:52                     ` Daniel Jacobowitz
2004-01-20 19:15                       ` Eli Zaretskii
2004-01-20 19:33                         ` Daniel Jacobowitz
2004-01-20 20:32                           ` Eli Zaretskii
2004-01-20 16:50                     ` Andrew Cagney
2004-01-20 19:10                       ` Eli Zaretskii
2004-01-20 21:29                   ` Andrew Cagney
2004-02-19 22:53                     ` Jeff Johnston

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=3FDA26B1.6010704@redhat.com \
    --to=jjohnstn@redhat.com \
    --cc=gdb-patches@sources.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