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

Daniel Jacobowitz
2004-01-20T19:33:55Z

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