From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: gdb@sourceware.cygnus.com Cc: jimb@cygnus.com, eliz@gnu.org, jtc@redback.com, hjl@lucon.org Subject: Proposal for `info float' layout Date: Sat, 30 Oct 1999 12:20:00 -0000 Message-id: <199910301920.VAA00427@delius.kettenis.local> X-SW-Source: 1999-q4/msg00190.html 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 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 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 > 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 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 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 To: gdb@sourceware.cygnus.com Subject: TotalView porting to Linux Date: Mon, 01 Nov 1999 11:32:00 -0000 Message-id: 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