[RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Jeff Johnston]

[-- 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

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Kevin Buettner]

On Dec 12,  3:36pm, Jeff Johnston wrote:

> 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.

I think this is (sort of) okay.  The assumption that's being made is that
the space needed to hold the bits on the target will be the same as that
on the host.  I think gdb has serious problems on host/target combinations
where this is untrue.

> The second problem is that extract_unsigned_integer() does the 
> same size test and returns failure so the call is pointless.

You mean extract_long_unsigned_integer(), right?  When I studied it
just now, the call didn't appear to be pointless.  It looks to me
like the code you're deleting is intended to handle the case where
the space needed by a LONGEST isn't large enough to hold the target's
type.

> 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.

I think this is the real problem.  The extract_long_unsigned_integer()
call attempts to fetch the bits from the type with no conversion
(other than leading zero removal if the type is overlong), but, if
I'm not mistaken, unpack_long() attempts to do a type conversion
and these two approaches to fetching the data definitely yield different
kinds of results.

> 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. 

I think you're right.

Something that I've wanted from time to time is a way to print the
bits comprising a value as some other type.  E.g, if I have a float,
I'd like to be be able to print the bits that comprise the float as an
int (or vice versa).  At first, I thought that was the intent of
print_scalar_formatted(), but I see now that it's not.  If the value
is stored in memory, you can do it with the appropriate cast, e.g,
if ``val'' is of type float, you can do ``print *(int *)&val'', but
AFAIK, you can't do this for values stored in registers or convenience
variables.  If we had such a mechanism, then I think we'd need some
code similar to the chunk that you're deleting.

Kevin

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Daniel Jacobowitz]

On Fri, Dec 12, 2003 at 03:17:04PM -0700, Kevin Buettner wrote:
> Something that I've wanted from time to time is a way to print the
> bits comprising a value as some other type.  E.g, if I have a float,
> I'd like to be be able to print the bits that comprise the float as an
> int (or vice versa).  At first, I thought that was the intent of
> print_scalar_formatted(), but I see now that it's not.  If the value
> is stored in memory, you can do it with the appropriate cast, e.g,
> if ``val'' is of type float, you can do ``print *(int *)&val'', but
> AFAIK, you can't do this for values stored in registers or convenience
> variables.  If we had such a mechanism, then I think we'd need some
> code similar to the chunk that you're deleting.

Personally, I've always thought that this is a more natural
interpretation of print/x on a floating point value.  Yes, I realize
it's not what GDB has ever done - I don't know what other people think
about this, or whether it would be a useful change, but since we only
support printing floating point numbers in base 10 it seems more useful
to dump the bit pattern rather than round to nearest integer.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[J. Johnston]

Kevin Buettner wrote:
> On Dec 12,  3:36pm, Jeff Johnston wrote:
> 
> 
>>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.
> 
> 
> I think this is (sort of) okay.  The assumption that's being made is that
> the space needed to hold the bits on the target will be the same as that
> on the host.  I think gdb has serious problems on host/target combinations
> where this is untrue.
> 
> 
>>The second problem is that extract_unsigned_integer() does the 
>>same size test and returns failure so the call is pointless.
> 
> 
> You mean extract_long_unsigned_integer(), right?  When I studied it
> just now, the call didn't appear to be pointless.  It looks to me
> like the code you're deleting is intended to handle the case where
> the space needed by a LONGEST isn't large enough to hold the target's
> type.
>

Yes, sorry about the name typo.  The extract_long_unsigned_integer() function 
ends up testing the type_size - leading zeroes vs the sizeof(LONGEST).  For most 
floats this will fail because of the biased exponent so it returns false.

   if (len <= (int) sizeof (LONGEST))
     {
       *pval = (LONGEST) extract_unsigned_integer (first_addr,
                                                   sizeof (LONGEST));
       return 1;
     }

   return 0;
}

> 
>>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.
> 
> 
> I think this is the real problem.  The extract_long_unsigned_integer()
> call attempts to fetch the bits from the type with no conversion
> (other than leading zero removal if the type is overlong), but, if
> I'm not mistaken, unpack_long() attempts to do a type conversion
> and these two approaches to fetching the data definitely yield different
> kinds of results.
> 
> 
>>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. 
> 
> 
> I think you're right.
> 
> Something that I've wanted from time to time is a way to print the
> bits comprising a value as some other type.  E.g, if I have a float,
> I'd like to be be able to print the bits that comprise the float as an
> int (or vice versa).  At first, I thought that was the intent of
> print_scalar_formatted(), but I see now that it's not.  If the value
> is stored in memory, you can do it with the appropriate cast, e.g,
> if ``val'' is of type float, you can do ``print *(int *)&val'', but
> AFAIK, you can't do this for values stored in registers or convenience
> variables.  If we had such a mechanism, then I think we'd need some
> code similar to the chunk that you're deleting.
> 

I suppose new format specifiers could always be added in the future to do just 
what you want.

-- Jeff J.

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[J. Johnston]

Ping.  Could we continue discussing this topic and come to some form of 
resolution?  The new additional ia64 test failures are annoying.

-- Jeff J.


J. Johnston wrote:
> Kevin Buettner wrote:
> 
>> On Dec 12,  3:36pm, Jeff Johnston wrote:
>>
>>
>>> 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.
>>
>>
>>
>> I think this is (sort of) okay.  The assumption that's being made is that
>> the space needed to hold the bits on the target will be the same as that
>> on the host.  I think gdb has serious problems on host/target 
>> combinations
>> where this is untrue.
>>
>>
>>> The second problem is that extract_unsigned_integer() does the same 
>>> size test and returns failure so the call is pointless.
>>
>>
>>
>> You mean extract_long_unsigned_integer(), right?  When I studied it
>> just now, the call didn't appear to be pointless.  It looks to me
>> like the code you're deleting is intended to handle the case where
>> the space needed by a LONGEST isn't large enough to hold the target's
>> type.
>>
> 
> Yes, sorry about the name typo.  The extract_long_unsigned_integer() 
> function ends up testing the type_size - leading zeroes vs the 
> sizeof(LONGEST).  For most floats this will fail because of the biased 
> exponent so it returns false.
> 
>   if (len <= (int) sizeof (LONGEST))
>     {
>       *pval = (LONGEST) extract_unsigned_integer (first_addr,
>                                                   sizeof (LONGEST));
>       return 1;
>     }
> 
>   return 0;
> }
> 
>>
>>> 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.
>>
>>
>>
>> I think this is the real problem.  The extract_long_unsigned_integer()
>> call attempts to fetch the bits from the type with no conversion
>> (other than leading zero removal if the type is overlong), but, if
>> I'm not mistaken, unpack_long() attempts to do a type conversion
>> and these two approaches to fetching the data definitely yield different
>> kinds of results.
>>
>>
>>> 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. 
>>
>>
>>
>> I think you're right.
>>
>> Something that I've wanted from time to time is a way to print the
>> bits comprising a value as some other type.  E.g, if I have a float,
>> I'd like to be be able to print the bits that comprise the float as an
>> int (or vice versa).  At first, I thought that was the intent of
>> print_scalar_formatted(), but I see now that it's not.  If the value
>> is stored in memory, you can do it with the appropriate cast, e.g,
>> if ``val'' is of type float, you can do ``print *(int *)&val'', but
>> AFAIK, you can't do this for values stored in registers or convenience
>> variables.  If we had such a mechanism, then I think we'd need some
>> code similar to the chunk that you're deleting.
>>
> 
> I suppose new format specifiers could always be added in the future to 
> do just what you want.
> 
> -- Jeff J.
> 
> 

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Andrew Cagney]

> Ping.  Could we continue discussing this topic and come to some form of resolution?  The new additional ia64 test failures are annoying.

I thought there was basic agreement with your change (It sux less then 
the current behavior :-).  Yes, change it.  That way, behavior such as:
	(gdb) print/x 1.0
will at least be more consistent.

Andrew

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Daniel Jacobowitz]

On Mon, Jan 19, 2004 at 05:57:04PM -0500, Andrew Cagney wrote:
> >Ping.  Could we continue discussing this topic and come to some form of 
> >resolution?  The new additional ia64 test failures are annoying.
> 
> I thought there was basic agreement with your change (It sux less then 
> the current behavior :-).  Yes, change it.  That way, behavior such as:
> 	(gdb) print/x 1.0
> will at least be more consistent.

Yeah, I agree, and re-reading Kevin's message I don't think he objects.

How do you all feel about a more sweeping change instead:
(gdb) set $doublevar = 2.0
(gdb) print doublevar
$1 = 2.0
(gdb) print (int) doublevar
$1 = 2
(gdb) print/x (int) doublevar
$1 = 2
(gdb) print/x doublevar
$1 = 0xc000000000000000
(gdb) print/i doublevar
???? [no preference really]

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Kevin Buettner]

On Mon, 19 Jan 2004 18:18:53 -0500
Daniel Jacobowitz <drow@mvista.com> wrote:

> On Mon, Jan 19, 2004 at 05:57:04PM -0500, Andrew Cagney wrote:
> > >Ping.  Could we continue discussing this topic and come to some form of 
> > >resolution?  The new additional ia64 test failures are annoying.
> > 
> > I thought there was basic agreement with your change (It sux less then 
> > the current behavior :-).  Yes, change it.  That way, behavior such as:
> > 	(gdb) print/x 1.0
> > will at least be more consistent.
> 
> Yeah, I agree, and re-reading Kevin's message I don't think he objects.

Right, no objection from me, but...

> How do you all feel about a more sweeping change instead:
> (gdb) set $doublevar = 2.0
> (gdb) print doublevar
> $1 = 2.0
> (gdb) print (int) doublevar
> $1 = 2
> (gdb) print/x (int) doublevar
> $1 = 2
> (gdb) print/x doublevar
> $1 = 0xc000000000000000

...I like this better.

Kevin

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Andrew Cagney]

> On Mon, Jan 19, 2004 at 05:57:04PM -0500, Andrew Cagney wrote:
> 
>> >Ping.  Could we continue discussing this topic and come to some form of 
>> >resolution?  The new additional ia64 test failures are annoying.
> 
>> 
>> I thought there was basic agreement with your change (It sux less then 
>> the current behavior :-).  Yes, change it.  That way, behavior such as:
>> 	(gdb) print/x 1.0
>> will at least be more consistent.
> 
> 
> Yeah, I agree, and re-reading Kevin's message I don't think he objects.
> 
> How do you all feel about a more sweeping change instead:
> (gdb) set $doublevar = 2.0
> (gdb) print doublevar
> $1 = 2.0
> (gdb) print (int) doublevar
> $1 = 2
> (gdb) print/x (int) doublevar
> $1 = 2
> (gdb) print/x doublevar
> $1 = 0xc000000000000000
> (gdb) print/i doublevar
> ???? [no preference really]

No.  That would be wrong.  print/<format> prints the value (not the 
implementation) using the specified format.  Being able to examine the 
underlying implementation in various formats is more of an "examine" 
command.

Andrew

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Daniel Jacobowitz]

On Mon, Jan 19, 2004 at 07:41:44PM -0500, Andrew Cagney wrote:
> >On Mon, Jan 19, 2004 at 05:57:04PM -0500, Andrew Cagney wrote:
> >
> >>>Ping.  Could we continue discussing this topic and come to some form of 
> >>>resolution?  The new additional ia64 test failures are annoying.
> >
> >>
> >>I thought there was basic agreement with your change (It sux less then 
> >>the current behavior :-).  Yes, change it.  That way, behavior such as:
> >>	(gdb) print/x 1.0
> >>will at least be more consistent.
> >
> >
> >Yeah, I agree, and re-reading Kevin's message I don't think he objects.
> >
> >How do you all feel about a more sweeping change instead:
> >(gdb) set $doublevar = 2.0
> >(gdb) print doublevar
> >$1 = 2.0
> >(gdb) print (int) doublevar
> >$1 = 2
> >(gdb) print/x (int) doublevar
> >$1 = 2
> >(gdb) print/x doublevar
> >$1 = 0xc000000000000000
> >(gdb) print/i doublevar
> >???? [no preference really]
> 
> No.  That would be wrong.  print/<format> prints the value (not the 
> implementation) using the specified format.  Being able to examine the 
> underlying implementation in various formats is more of an "examine" 
> command.

Andrew, please explain to us all how you can respond to "I think this
would be a better, different-than-the-current behavior" with "No, that
would be wrong".

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Daniel Jacobowitz]

On Mon, Jan 19, 2004 at 09:04:48PM -0500, Andrew Cagney wrote:
> >(gdb) print/x doublevar
> >>>$1 = 0xc000000000000000
> >>>(gdb) print/i doublevar
> >>>???? [no preference really]
> >
> >>
> >>No.  That would be wrong.  print/<format> prints the value (not the 
> >>implementation) using the specified format.  Being able to examine the 
> >>underlying implementation in various formats is more of an "examine" 
> >>command.
> >
> >
> >Andrew, please explain to us all how you can respond to "I think this
> >would be a better, different-than-the-current behavior" with "No, that
> >would be wrong".
> 
> "us all"?

Yes, since "That would be wrong" is a pretty sweeping policy statement
for GDB.  It indicates the existance of an absolute standard that we
need to adhere to.  If there is one, I've missed it, please add it to
the manual.

> "print" displays the value, not the underlying representation, using 
> normal language rules. Consider:
> 	int i = 1.0;
> 	extern foo (int i);
> 	foo (1.0:
> which don't leave something like 0xc0000000 in i.  On the other hand 

So if you use no format characters, you'll get the expected result.  I
think at least one word is missing from the above example...

> "examine" lets you display the underlying [memory] representation in 
> various forms.
> 
> The problem here is not print/f, but rather that there isn't way to 
> examine the underlying representation of non-memory values (most often 
> registers) this leaves people attempting:
> 	x/x $fp0
> and then:
> 	p/x $fp0
> :-(

My point is that we can _change_ the behavior of print.  I think that
it is reasonable for the process to be something like this:
  print /format expression
    Evaluate expression
    Expression has a type
     Examine the value of that type according to /format
      [interpret its bits as a double, or as hex, or whatever...]

This isn't the first time this has come up, Jim (?) made a similar
suggestion some time ago for the case of ObjC.  I think that I
disagreed with it at the time, but I've got a history of being
inconsistent.

Think about it.  What use do these have:
  p/f int_var
  p/x double_var

None that I can see.  p (double) int_var is obviously <int_var>.0 in C,
and p/x (int) double_var is obviously 0x<truncate(double_var)>, but the
format specifiers don't add value.  Here's some value they could add.
Now, for ints vs. pointers it may be a little messier.

This might even let me solve a long-standing complaint.  Given $r1 =
0x62636566, I'd love to have a way to make gdb print "bcef".  Or "fceb"
or whatever else.  p/s $r1?  p/x 0x62636566?  Examine does an implicit
dereference and print doesn't, so this seems like a logical use of
printf.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Eli Zaretskii]

> Date: Tue, 20 Jan 2004 00:48:36 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> My point is that we can _change_ the behavior of print.  I think that
> it is reasonable for the process to be something like this:
>   print /format expression
>     Evaluate expression
>     Expression has a type
>      Examine the value of that type according to /format
>       [interpret its bits as a double, or as hex, or whatever...]
> 
> This isn't the first time this has come up, Jim (?) made a similar
> suggestion some time ago for the case of ObjC.  I think that I
> disagreed with it at the time, but I've got a history of being
> inconsistent.
> 
> Think about it.  What use do these have:
>   p/f int_var
>   p/x double_var
> 
> None that I can see.  p (double) int_var is obviously <int_var>.0 in C,
> and p/x (int) double_var is obviously 0x<truncate(double_var)>, but the
> format specifiers don't add value.  Here's some value they could add.
> Now, for ints vs. pointers it may be a little messier.
> 
> This might even let me solve a long-standing complaint.  Given $r1 =
> 0x62636566, I'd love to have a way to make gdb print "bcef".  Or "fceb"
> or whatever else.  p/s $r1?  p/x 0x62636566?  Examine does an implicit
> dereference and print doesn't, so this seems like a logical use of
> printf.

May I wave the truce flag here?

Daniel, do you object to having the feature you wanted in `x', rather
than in `print'?  If you do, could you please explain why?

If having this on `x' is not something we agree to, how about a
`maint' command, or a new format letter for `print' that would
specifically be designed to reveal the bit pattern of the value as it
would be stored in memory?

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Daniel Jacobowitz]

On Tue, Jan 20, 2004 at 08:51:09AM +0200, Eli Zaretskii wrote:
> > Date: Tue, 20 Jan 2004 00:48:36 -0500
> > From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > My point is that we can _change_ the behavior of print.  I think that
> > it is reasonable for the process to be something like this:
> >   print /format expression
> >     Evaluate expression
> >     Expression has a type
> >      Examine the value of that type according to /format
> >       [interpret its bits as a double, or as hex, or whatever...]
> > 
> > This isn't the first time this has come up, Jim (?) made a similar
> > suggestion some time ago for the case of ObjC.  I think that I
> > disagreed with it at the time, but I've got a history of being
> > inconsistent.
> > 
> > Think about it.  What use do these have:
> >   p/f int_var
> >   p/x double_var
> > 
> > None that I can see.  p (double) int_var is obviously <int_var>.0 in C,
> > and p/x (int) double_var is obviously 0x<truncate(double_var)>, but the
> > format specifiers don't add value.  Here's some value they could add.
> > Now, for ints vs. pointers it may be a little messier.
> > 
> > This might even let me solve a long-standing complaint.  Given $r1 =
> > 0x62636566, I'd love to have a way to make gdb print "bcef".  Or "fceb"
> > or whatever else.  p/s $r1?  p/x 0x62636566?  Examine does an implicit
> > dereference and print doesn't, so this seems like a logical use of
> > printf.
> 
> May I wave the truce flag here?

By all means :)

> Daniel, do you object to having the feature you wanted in `x', rather
> than in `print'?  If you do, could you please explain why?

Because, at the moment, we have a common syntax shared by print and
examine - but some of the options don't make sense (I claim) for print. 
But they do all make sense for examine.  Witness:

(gdb) help x
Examine memory: x/FMT ADDRESS.

For a double located in memory, you can already do x/2x &double_var,
and I often do.  You can't apply & to a register; I suppose that would
be another reasonable alternative, but that changes the C expression
syntax instead of the syntax of a specific GDB command, and I don't
much fancy the idea.  You can't apply & to a constant, either.  I've
wanted to do p/x 2.0 and have some way to get the representation out
from that.  Right now the only way I know is:
(gdb) set *(double *)($sp - 1024) = 2.0
(gdb) x/2x $sp - 1024

Which I try to avoid doing, for obvious reasons.

> If having this on `x' is not something we agree to, how about a
> `maint' command, or a new format letter for `print' that would
> specifically be designed to reveal the bit pattern of the value as it
> would be stored in memory?

I don't think that it is a maintenance command - see my example about
p/s 0x62636566.  I also think that adding a new print format flag that
examines without changing the existing ones will be more confusing.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Eli Zaretskii]

> Date: Tue, 20 Jan 2004 09:52:25 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> > Daniel, do you object to having the feature you wanted in `x', rather
> > than in `print'?  If you do, could you please explain why?
> 
> Because, at the moment, we have a common syntax shared by print and
> examine - but some of the options don't make sense (I claim) for print. 
> But they do all make sense for examine.

Sorry, I don't see how is this relevant.  Suppose we add a new format
letter to `x', one that doesn't exist in `print'--would that be okay,
and if not, why not?

> I don't think that it is a maintenance command

We have wuite a few examples of obscure features that we pushed to
maint.  I don't see why this one cannot.

I do agree that it's better to have it on a regular command.

> I also think that adding a new print format flag that examines
> without changing the existing ones will be more confusing.

Please tell why.  I don't see why it would be confusing to add a new
format that is defined to always show the memory representation of the
value in hex.

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Daniel Jacobowitz]

On Tue, Jan 20, 2004 at 09:10:55PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 20 Jan 2004 09:52:25 -0500
> > From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > > Daniel, do you object to having the feature you wanted in `x', rather
> > > than in `print'?  If you do, could you please explain why?
> > 
> > Because, at the moment, we have a common syntax shared by print and
> > examine - but some of the options don't make sense (I claim) for print. 
> > But they do all make sense for examine.
> 
> Sorry, I don't see how is this relevant.  Suppose we add a new format
> letter to `x', one that doesn't exist in `print'--would that be okay,
> and if not, why not?
> 
> > I don't think that it is a maintenance command
> 
> We have wuite a few examples of obscure features that we pushed to
> maint.  I don't see why this one cannot.
> 
> I do agree that it's better to have it on a regular command.
> 
> > I also think that adding a new print format flag that examines
> > without changing the existing ones will be more confusing.
> 
> Please tell why.  I don't see why it would be confusing to add a new
> format that is defined to always show the memory representation of the
> value in hex.

I'll respond to these all together, since there's really the same
answer to all of them: I think there is a general unimplemented feature
here, not just the specific "show me the hex representation of this
double".  Examples I have in mind:
  - Displaying an integer to a sequence of characters
      p/s 0x6263 -> "ab"
  - Displaying a double-precision value in hex:
      p/x 2.0 -> 0x4000000000000000
  - Displaying a double-precision value in binary:
      p/t 2.0 -> 01000000000000000000000000000000
                 00000000000000000000000000000000
  - Displaying an integer (hex or otherwise) value as a double
    p/f 0x4000000000000000LL -> 2.0
  - Displaying an integer (hex or otherwise) value as a long
    double - this one is trickier, since we don't normally have an
    integer type that is big enough, but if we did:
    p/gf 0x400000000000000000000000LLL -> 2.0

I didn't pick these examples at random.  I've wanted to do every single
one of these in the past three months, for values in registers rather
than typed-in constants.  I had to store them to the inferior's memory
to do it.  And then x/2x gives you the two words broken up, and you
get:
  0x00000000 0x40000000
when perhaps you wanted:
  0x40000000_00000000
They both indicate that on a little endian system the set bit is in the
most-significant, therefore highest-byte-addressed, byte.

I think that adding a flag to show the representation in hex would be
intuitive, but not general enough, and that extending the existing /x
to do the same thing would be more natural.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Eli Zaretskii]

> Date: Tue, 20 Jan 2004 14:33:49 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> I'll respond to these all together, since there's really the same
> answer to all of them: I think there is a general unimplemented feature
> here, not just the specific "show me the hex representation of this
> double".  Examples I have in mind:
>   - Displaying an integer to a sequence of characters
>       p/s 0x6263 -> "ab"
>   - Displaying a double-precision value in hex:
>       p/x 2.0 -> 0x4000000000000000
>   - Displaying a double-precision value in binary:
>       p/t 2.0 -> 01000000000000000000000000000000
>                  00000000000000000000000000000000
>   - Displaying an integer (hex or otherwise) value as a double
>     p/f 0x4000000000000000LL -> 2.0
>   - Displaying an integer (hex or otherwise) value as a long
>     double - this one is trickier, since we don't normally have an
>     integer type that is big enough, but if we did:
>     p/gf 0x400000000000000000000000LLL -> 2.0

Sounds like there's a place for a new command, since what we want here
is a command that would interpret a value as some different type.  Do
you agree?

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Andrew Cagney]

> Daniel, do you object to having the feature you wanted in `x', rather
> than in `print'?  If you do, could you please explain why?
> 
> If having this on `x' is not something we agree to, how about a
> `maint' command, or a new format letter for `print' that would
> specifically be designed to reveal the bit pattern of the value as it
> would be stored in memory?

Try:

	(gdb) x 1.0
	0x000001: 0x12345678
	(gdb) x/v 1.0
	0x000000: 0xc0000000

or more notably:

	(gdb) print struct_val
	{ i = 1, j = 2, k = 1.0 }
	(gdb) info location struct_val
	struct_val is a dwarf2 location expression, its value is scattered 
across memory and registers
	(gdb) x/v struct_val
	0x00000000:  0x00010002   0xc0000000

Andrew

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Eli Zaretskii]

> Date: Tue, 20 Jan 2004 11:50:06 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> Try:
> 
> 	(gdb) x 1.0
> 	0x000001: 0x12345678
> 	(gdb) x/v 1.0
> 	0x000000: 0xc0000000
> 
> or more notably:
> 
> 	(gdb) print struct_val
> 	{ i = 1, j = 2, k = 1.0 }
> 	(gdb) info location struct_val
> 	struct_val is a dwarf2 location expression, its value is scattered 
> across memory and registers
> 	(gdb) x/v struct_val
> 	0x00000000:  0x00010002   0xc0000000

Andrew, are you saying that "x/v" is already in GDB and does
everything Daniel asked for?

Anyway, I don't find the /v specifier in the manual.  Is this
implemented, or is this just a suggestion for a new feature?

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Andrew Cagney]

> 
> My point is that we can _change_ the behavior of print.  I think that
> it is reasonable for the process to be something like this:
>   print /format expression
>     Evaluate expression
>     Expression has a type
>      Examine the value of that type according to /format
>       [interpret its bits as a double, or as hex, or whatever...]
> 
> This isn't the first time this has come up, Jim (?) made a similar
> suggestion some time ago for the case of ObjC.  I think that I
> disagreed with it at the time, but I've got a history of being
> inconsistent.
> 
> Think about it.  What use do these have:
>   p/f int_var
>   p/x double_var
> 
> None that I can see.  p (double) int_var is obviously <int_var>.0 in C,
> and p/x (int) double_var is obviously 0x<truncate(double_var)>, but the
> format specifiers don't add value.

Apparent lack of value is not a bug.  Often its a sign of well thought 
out design.

Consider:
	struct st { int i:12; j:4; short s } stv = { 1, 2, 3 };
(something that is currently causing the linux kernel grief - GCC 3.4 
finally rejects typeof stv.i).  For:
	(gdb) print stv
	{ 1, 2, 3}
	(gdb) print/f stv
	{ 1.0, 2.0, 3.0 }
GDB interprets stv.i and stv.j as _abstract_ values and then formats and 
displays them accordingly.  At the same time for:
	(gdb) x/b &stv
	0x1234000:  0x00120003
GDB displays the bits used in the underlying representation of stv.

The thing that is missing here, and I suspect at the time this code was 
written was never thought to be a problem so ignored, is a mechanism for 
examining / manipulating the underlying representation of a value that 
is not sequentially laid out in memory.  For instance:
	(gdb) ptype v
	vector int i[4]
	(gdb) print &v[1] - &v[0]
	1
should always work (that's valid C), only it doesn't when the value 
isn't in memory:
	(gdb) print &$mm0.v8_int8[1] - &$mm0.v8_int8[0]
	Attempt to take address of value not located in memory.
Similarly, it should be possible to interpret the underlying 
representation of an arbitrary value vis (Eli, yes, /v doesn't exist):
	(gdb) x/8c &$mm0
	(gdb) x/f &$mm0.v2_int32[1]
or with a new /v[alue] option (for want of a better letter):
	(gdb) x/8vc $mm0
but I suspect that getting & working, while harder, would be better.

Andrew




>  Here's some value they could add.
> Now, for ints vs. pointers it may be a little messier.
> 
> This might even let me solve a long-standing complaint.  Given $r1 =
> 0x62636566, I'd love to have a way to make gdb print "bcef".  Or "fceb"
> or whatever else.  p/s $r1?  p/x 0x62636566?  Examine does an implicit
> dereference and print doesn't, so this seems like a logical use of
> printf.
> 

Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Jeff Johnston]

Just to inform that the original patch has been checked in.

-- Jeff J.

Andrew Cagney wrote:
>>
>> My point is that we can _change_ the behavior of print.  I think that
>> it is reasonable for the process to be something like this:
>>   print /format expression
>>     Evaluate expression
>>     Expression has a type
>>      Examine the value of that type according to /format
>>       [interpret its bits as a double, or as hex, or whatever...]
>>
>> This isn't the first time this has come up, Jim (?) made a similar
>> suggestion some time ago for the case of ObjC.  I think that I
>> disagreed with it at the time, but I've got a history of being
>> inconsistent.
>>
>> Think about it.  What use do these have:
>>   p/f int_var
>>   p/x double_var
>>
>> None that I can see.  p (double) int_var is obviously <int_var>.0 in C,
>> and p/x (int) double_var is obviously 0x<truncate(double_var)>, but the
>> format specifiers don't add value.
> 
> 
> Apparent lack of value is not a bug.  Often its a sign of well thought 
> out design.
> 
> Consider:
>     struct st { int i:12; j:4; short s } stv = { 1, 2, 3 };
> (something that is currently causing the linux kernel grief - GCC 3.4 
> finally rejects typeof stv.i).  For:
>     (gdb) print stv
>     { 1, 2, 3}
>     (gdb) print/f stv
>     { 1.0, 2.0, 3.0 }
> GDB interprets stv.i and stv.j as _abstract_ values and then formats and 
> displays them accordingly.  At the same time for:
>     (gdb) x/b &stv
>     0x1234000:  0x00120003
> GDB displays the bits used in the underlying representation of stv.
> 
> The thing that is missing here, and I suspect at the time this code was 
> written was never thought to be a problem so ignored, is a mechanism for 
> examining / manipulating the underlying representation of a value that 
> is not sequentially laid out in memory.  For instance:
>     (gdb) ptype v
>     vector int i[4]
>     (gdb) print &v[1] - &v[0]
>     1
> should always work (that's valid C), only it doesn't when the value 
> isn't in memory:
>     (gdb) print &$mm0.v8_int8[1] - &$mm0.v8_int8[0]
>     Attempt to take address of value not located in memory.
> Similarly, it should be possible to interpret the underlying 
> representation of an arbitrary value vis (Eli, yes, /v doesn't exist):
>     (gdb) x/8c &$mm0
>     (gdb) x/f &$mm0.v2_int32[1]
> or with a new /v[alue] option (for want of a better letter):
>     (gdb) x/8vc $mm0
> but I suspect that getting & working, while harder, would be better.
> 
> Andrew
> 
> 
> 
> 
>>  Here's some value they could add.
>> Now, for ints vs. pointers it may be a little messier.
>>
>> This might even let me solve a long-standing complaint.  Given $r1 =
>> 0x62636566, I'd love to have a way to make gdb print "bcef".  Or "fceb"
>> or whatever else.  p/s $r1?  p/x 0x62636566?  Examine does an implicit
>> dereference and print doesn't, so this seems like a logical use of
>> printf.
>>
> 
> 
>