Proposal for `info float' layout

[Mark Kettenis <kettenis@wins.uva.nl>]

Based on the input from the people on the list, I have made a proposal
for how the output of `info float' should look.  Please take a look at
it and don't hesitate to mail me your comments.

Here is how I think the output of `info float' (for a ficticious FPU
state) should look like:

------------------------------------------------------------------

  R7: Valid   0x00000000000000000000 1.0000000000000000000
=>R6: Special 0x00000000000000000000 +QNaN
  R5: Empty   0x00000000000000000000
  R4: Zero    0x00000000000000000000 -0
  R3: Special 0x00000000000000000000 0.0024438394034300000 Denormal
  R2: Empty   0x00000000000000000000 
  R1: Empty   0x00000000000000000000
  R0: Empty   0x00000000000000000000

Status Word:         0x0000  IE DE ZE OE UE PE  ES  SF  C0 C1 C2 C3
                       TOP: 6
Control Word:        0x0000  IM DM ZM OM UM PM
                       PC: Extended Precision (64-bits)
                       RC: Round to nearest
Tag Word:            0x0000
Instruction Pointer: 0x00:0x00000000
Operand Pointer:     0x00:0x00000000
Opcode:              0x0000

-------------------------------------------------------------------

The registers are printed in "physical" order, with the same names as
in the Intel documentation.  After the register name the
interpretation of the bits relevant for this register in the tag word
is printed, again using the terminology used by the Intel
documentation.  Then the register contents are printed, in hexadecimal
notation.  What's printed in the next column depends on the tag.  If
the register is `Valid', the floating point value is printed using the
"%g" specifier.  If the register is `Special', some additional
interpretation on the contents are done and for infinities and NaN's
one of the following is printed: `-Inf', `+Inf', `-SNaN', `+SNaN',
`-QNaN', `+QNaN'.  If the value is a denormal floating point number,
the value is printed and `Denormal' is printed in the last column.  If
the value is `Zero', `-0' or `+0' is printed.  The top of the stack is
indicated by `=>' in the first columns.

After the registers, the status word is printed.  All flags that are
set are printed in the notation that Intel uses.  They are always
printed in the same location.  On a seperate line the contents of the
top of stack register (TOP) are printed.

Next is the control word.  The flags are printed, such that the mask
flags are printed exactly below the corresponding flags in the status
word.  The contents of the precision control register (PC) and
rounding control register (RC) are printed on a seperate line.

The tag word follows.  Only the raw contents are printed.

After the tag word follow the instruction and operand pointers, in
segment:offset notation.

The last thing that is printed is the opcode, including the bits that
are stripped because they're always the same.


There has been a suggestion that `info float' should interpret the C0,
C1, C2 and C3 flags of the status word.  I don't think that this is
feasable since it is pretty complicated.

It has also been suggested that the mnemonic associated with the
opcode should be printed.  While I think this is a good idea it is not
really easy to use libopcodes for this purpose.  So my first
implementation will not contain this feature.

Mark
From eliz@gnu.org Sun Oct 31 01:26:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: kettenis@wins.uva.nl
Cc: gdb@sourceware.cygnus.com, jimb@cygnus.com, jtc@redback.com, hjl@lucon.org
Subject: Re: Proposal for `info float' layout
Date: Sun, 31 Oct 1999 01:26:00 -0000
Message-id: <199910310825.DAA16128@mescaline.gnu.org>
References: <199910301920.VAA00427@delius.kettenis.local>
X-SW-Source: 1999-q4/msg00191.html
Content-length: 1922

> Based on the input from the people on the list, I have made a proposal
> for how the output of `info float' should look.  Please take a look at
> it and don't hesitate to mail me your comments.

I like this layout very much!  The following are some minor comments.

> Status Word:         0x0000  IE DE ZE OE UE PE  ES  SF  C0 C1 C2 C3

Perhaps it would be better to reverse the order of Ci bits: C3 C2 C1 C0.  
This is how Intel docs print them, so it might be easier to interpret
them in that way.

> What's printed in the next column depends on the tag.  If
> the register is `Valid', the floating point value is printed using the
> "%g" specifier.

I don't think we can be sure that "%g" will yield enough significant
digits on all supported platforms.  I'd think "%.19Lg" is much
better (LDBL_EPSILON is 1.08e-19 on my machine).  I expect people to
want to see all the significant digits of the 80-bit format stored in
the registers, and the defaults required by ANSI C aren't good enough.

> If the register is `Special', some additional
> interpretation on the contents are done and for infinities and NaN's
> one of the following is printed: `-Inf', `+Inf', `-SNaN', `+SNaN',
> `-QNaN', `+QNaN'.  If the value is a denormal floating point number,
> the value is printed and `Denormal' is printed in the last column.

There is one more possibility: `Unnormal'.  These are the cases where
the mantissa has some of its high bits zeroed, but the (biased)
exponent is NOT zero.  This can happen if some random junk is
interpreted as an FP number.  It is important to single out these
cases because it almost invariably means a bug, while denormals can
happen in correct code.

> It has also been suggested that the mnemonic associated with the
> opcode should be printed.  While I think this is a good idea it is not
> really easy to use libopcodes for this purpose.

What are the difficulties with using libopcodes?
From kettenis@wins.uva.nl Sun Oct 31 06:20:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: eliz@gnu.org
Cc: gdb@sourceware.cygnus.com, jimb@cygnus.com, jtc@redback.com, hjl@lucon.org
Subject: Re: Proposal for `info float' layout
Date: Sun, 31 Oct 1999 06:20:00 -0000
Message-id: <199910311419.PAA01189@delius.kettenis.local>
References: <199910301920.VAA00427@delius.kettenis.local> <199910310825.DAA16128@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00192.html
Content-length: 3903

   Date: Sun, 31 Oct 1999 03:25:57 -0500
   From: Eli Zaretskii <eliz@gnu.org>

   > Based on the input from the people on the list, I have made a proposal
   > for how the output of `info float' should look.  Please take a look at
   > it and don't hesitate to mail me your comments.

   I like this layout very much!  The following are some minor comments.

Thanks!

   > Status Word:         0x0000  IE DE ZE OE UE PE  ES  SF  C0 C1 C2 C3

   Perhaps it would be better to reverse the order of Ci bits: C3 C2 C1 C0.  
   This is how Intel docs print them, so it might be easier to interpret
   them in that way.

The docs I'm looking at aren't very consistent.  The text refers to C0
through C3, the status word diagram lists them in reverse order (since
C3 is the highest order bit, the interpretation table lists them in
the order C0, C3, C2, C1, and in the diagram that shows how the
condition codes are moved to the EFLAGS register they'r listed in the
order C0, C1, C2, C3 again.  I have no problem with changing the
order if someone has a real preference, but in absence of a convincing
argument I think the current order is the most logical one.

   > What's printed in the next column depends on the tag.  If
   > the register is `Valid', the floating point value is printed using the
   > "%g" specifier.

   I don't think we can be sure that "%g" will yield enough significant
   digits on all supported platforms.  I'd think "%.19Lg" is much
   better (LDBL_EPSILON is 1.08e-19 on my machine).  I expect people to
   want to see all the significant digits of the 80-bit format stored in
   the registers, and the defaults required by ANSI C aren't good enough.

I'm using "%+26.20Lg" right now.  That should be enough to print all
significant digits shouldn't it.

   > If the register is `Special', some additional
   > interpretation on the contents are done and for infinities and NaN's
   > one of the following is printed: `-Inf', `+Inf', `-SNaN', `+SNaN',
   > `-QNaN', `+QNaN'.  If the value is a denormal floating point number,
   > the value is printed and `Denormal' is printed in the last column.

   There is one more possibility: `Unnormal'.  These are the cases where
   the mantissa has some of its high bits zeroed, but the (biased)
   exponent is NOT zero.  This can happen if some random junk is
   interpreted as an FP number.  It is important to single out these
   cases because it almost invariably means a bug, while denormals can
   happen in correct code.

Indeed.  After I did some actual coding I realized that this part of
my proposal isn't really sufficient.  First, trusting the tag word to
accurately describe the contents of a register is dangerous, since in
gdb one can change the contents of a register without changing the
tag.  So the processing described above will have to take place for
all tags, not only `Special'.  Besides `Unnormal', there are several
other possibilities of what Intel calls `Unsupported Extended-Real
Encodings'.  Of these encodings only Pseudo-denormal is valid as an
operand, so I think it is a good idea to classify those.  The FPU
doesn't generate them, but user code could.  All other unsupported
encodings will simply display `Unsupported'.

   > It has also been suggested that the mnemonic associated with the
   > opcode should be printed.  While I think this is a good idea it is not
   > really easy to use libopcodes for this purpose.

   What are the difficulties with using libopcodes?

The only entry points are `print_insn_i386_att' and
`print_insn_i386_intel'.  These functions try to decode a full
instruction, which is bad since the FPU opcode register only contains
the opcode bytes, and no information about the operand.  Of course we
could disassemble the instruction pointed at by the FPU instruction
pointer, but I'd rather just print the mnemonic based on the contents
of the FPU opcode register.

Mark
From eliz@gnu.org Sun Oct 31 14:37:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: kettenis@wins.uva.nl
Cc: gdb@sourceware.cygnus.com, jimb@cygnus.com, jtc@redback.com, hjl@lucon.org
Subject: Re: Proposal for `info float' layout
Date: Sun, 31 Oct 1999 14:37:00 -0000
Message-id: <199910312236.RAA12230@mescaline.gnu.org>
References: <199910301920.VAA00427@delius.kettenis.local> <199910310825.DAA16128@mescaline.gnu.org> <199910311419.PAA01189@delius.kettenis.local>
X-SW-Source: 1999-q4/msg00193.html
Content-length: 1498

> I'm using "%+26.20Lg" right now.  That should be enough to print all
> significant digits shouldn't it.

Does "%+26.20Lg" have enough room for the exponent and the decimal?
The exponent prints as 6 characters: "e+NNNN", which makes it 7
characters together with the decimal point.  So it seems like
"%+27.20Lg" is better, no?

Actually, the last digit would be garbled if you print 20 significant
digits, so you might try "%+26.19Lg".  I usually find it instructional
to print some simple constants, like 2 and Pi, and results of simple
calculations, like 2*2, to see if the format is okay.

>    > It has also been suggested that the mnemonic associated with the
>    > opcode should be printed.  While I think this is a good idea it is not
>    > really easy to use libopcodes for this purpose.
> 
>    What are the difficulties with using libopcodes?
> 
> The only entry points are `print_insn_i386_att' and
> `print_insn_i386_intel'.  These functions try to decode a full
> instruction, which is bad since the FPU opcode register only contains
> the opcode bytes, and no information about the operand.  Of course we
> could disassemble the instruction pointed at by the FPU instruction
> pointer, but I'd rather just print the mnemonic based on the contents
> of the FPU opcode register.

Oh, I thought you *were* trying to disassemble at the IP ;-)

Well, how about looking up the opcode in a table that lists the
corresponding mnemonics?  There aren't that many FP instructions, are
there?
From 666@grafzahl.de Mon Nov 01 05:18:00 1999
From: Daniel Vogel <666@grafzahl.de>
To: gdb@sourceware.cygnus.com
Subject: handling of unknown signals
Date: Mon, 01 Nov 1999 05:18:00 -0000
Message-id: <381D94AD.B37EC167@grafzahl.de>
X-SW-Source: 1999-q4/msg00194.html
Content-length: 526

hi`

when trying to debug a program that uses threads gbd (4.18) stops with:

Program received signal ?, Unknown signal.

and I can't continue the program afterwards. Well, the program runs fine
without invoking gdb - so I want to tell gdb to ignore unknown signals.
I read in the docs/info/man pages how to ignore signals, but there was
no hint on how to ignore unknown signals. Could you please help me with
this :-)

btw, the problem arose when upgrading from SuSE 6.1 to 6.2...

-- 
Daniel Vogel

666 @ http://grafzahl.de
From hjl@lucon.org Mon Nov 01 09:09:00 1999
From: hjl@lucon.org (H.J. Lu)
To: kettenis@wins.uva.nl (Mark Kettenis)
Cc: gdb@sourceware.cygnus.com, jimb@cygnus.com, eliz@gnu.org, jtc@redback.com, hjl@lucon.org
Subject: Re: Proposal for `info float' layout
Date: Mon, 01 Nov 1999 09:09:00 -0000
Message-id: <19991101170951.082811B493@ocean.lucon.org>
References: <199910301920.VAA00427@delius.kettenis.local>
X-SW-Source: 1999-q4/msg00195.html
Content-length: 984

> 
> Based on the input from the people on the list, I have made a proposal
> for how the output of `info float' should look.  Please take a look at
> it and don't hesitate to mail me your comments.
> 
> Here is how I think the output of `info float' (for a ficticious FPU
> state) should look like:
> 
> ------------------------------------------------------------------
> 
>   R7: Valid   0x00000000000000000000 1.0000000000000000000
> =>R6: Special 0x00000000000000000000 +QNaN
>   R5: Empty   0x00000000000000000000
>   R4: Zero    0x00000000000000000000 -0
>   R3: Special 0x00000000000000000000 0.0024438394034300000 Denormal
>   R2: Empty   0x00000000000000000000 
>   R1: Empty   0x00000000000000000000
>   R0: Empty   0x00000000000000000000
> 

May I suggest we use

R3: Special 0x00000000000000000000 Denormal 0.0024438394034300000
R4: Empty   0x00000000000000000000 Zero	    0
R4: Empty   0x00000000000000000000 Normal   1.0

It is more consistent and easy to read.


H.J.
From kettenis@wins.uva.nl Mon Nov 01 10:43:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: hjl@lucon.org
Cc: gdb@sourceware.cygnus.com, jimb@cygnus.com, eliz@gnu.org, jtc@redback.com, hjl@lucon.org
Subject: Re: Proposal for `info float' layout
Date: Mon, 01 Nov 1999 10:43:00 -0000
Message-id: <199911011843.TAA00201@delius.kettenis.local>
References: <19991101170951.082811B493@ocean.lucon.org>
X-SW-Source: 1999-q4/msg00196.html
Content-length: 1633

   Date: Mon, 1 Nov 1999 09:09:50 -0800 (PST)
   From: hjl@lucon.org (H.J. Lu)

   May I suggest we use

   R3: Special 0x00000000000000000000 Denormal 0.0024438394034300000
   R4: Empty   0x00000000000000000000 Zero	    0
   R4: Empty   0x00000000000000000000 Normal   1.0

   It is more consistent and easy to read.

Thanks for your suggestion.  It gives me the opportunity to say a few
things about how I came to my proposal for the new layout.

While your suggested layout may seem more consistent, I don't think it
is easier to read.

Keep in mind that GDB is a debugger.  We should try to create the
layout that is most useful for finding bugs.  Based on this principle
I made some decisions:

 * My code deliberately does not try to interpret the contents of
   empty registers.  Doing so would needlesly clutter the display with
   information that is almost certainly irrelevent, thus making it
   harder to find information that is relevant.  If you really want
   the contents of an empty register as a floating point number, you
   can always display the register by using GDB's `print' command.

 * My code deliberately prints only a further classification of a
   floating point number if it is `Denormal' or `Pseudo-denormal'.
   This makes denormals stand out which is important since a denormal
   is a clear sign for problematic code.  The user's program might
   perform poorly since it is losing precision.

   I think zeroes stand out enough for themselves, and a normal number
   is ... well, a normal number.  Nothing special and doesn't require
   any additional attention.  Only its value is relevant.

Mark
From shebs@cygnus.com Mon Nov 01 11:32:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: TotalView porting to Linux
Date: Mon, 01 Nov 1999 11:32:00 -0000
Message-id: <xdemeaxb1c.fsf@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00197.html
Content-length: 466

It looks like GDB is going to get some serious competition on
GNU/Linux, in the form of TotalView, which is a pretty elaborate
debugger for parallel applications.

It would be a shame if GDB (plus the various GUIs) were not the most
powerful debugger available on Linux; so we should be thinking about
how to provide TotalView's functionality within the GDB framework.

See http://www.embeddedtechnology.com/read/nl19991026/25177 for a
few more bits.

								Stan