Re: x86 fpu

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

   From: Jim Blandy <jimb@cygnus.com>
   Date: 19 Oct 1999 13:47:30 -0500


   > I saw some changes for x86. But I didn't see changes to enable x86
   > FPU support on Linux. Is that true?

   That's right.  See the prior discussion on this list.  I'm still
   soliciting comments from x86 maintainers on the code.  Once people
   have had a chance to look it over, then we'll be adding generic x86
   FPU support, which Linux will use.

But some FPU support is already present in the current code.  You
should be able to look at the FPU registers (via the "info registers"
command or their individual names) and modify their values.  The "info
float" command won't work yet though.  This should be fixed in the
near future by having the generic x86 FPU support that Jim is talking
about.

HJ, what else will have to happen with GDB before you will consider
dropping your special Linux GDB based on 4.17?  IMHO we should make
sure that the Linux community starts doing their GDB development based
on the current CVS version as soom as possible.

Mark
From hjl@lucon.org Tue Oct 19 16:52:00 1999
From: hjl@lucon.org (H.J. Lu)
To: kettenis@wins.uva.nl (Mark Kettenis)
Cc: gdb@sourceware.cygnus.com
Subject: Re: x86 fpu
Date: Tue, 19 Oct 1999 16:52:00 -0000
Message-id: <19991019235249.917DC1B494@ocean.lucon.org>
References: <199910192343.BAA00273@delius.kettenis.local>
X-SW-Source: 1999-q4/msg00061.html
Content-length: 640

> 
> HJ, what else will have to happen with GDB before you will consider
> dropping your special Linux GDB based on 4.17?  IMHO we should make
> sure that the Linux community starts doing their GDB development based
> on the current CVS version as soom as possible.
> 

My Linux gdb has supports for

1. x86 fpu.
2. "better" x86 hw watchpoint. It is different from the normal x86
hw watchpoint which I don't like.
3. linuxthreads support for alpha and powerpc.
4. regex in glibc 2.

I have patches for #2, #3 and #4. Since there is a backlog for
x86 changes, I want to wait until #1 is done before I submit them.

-- 
H.J. Lu (hjl@gnu.org)
From jimb@cygnus.com Tue Oct 19 21:23:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Tue, 19 Oct 1999 21:23:00 -0000
Message-id: <np4sfmk6dq.fsf@zwingli.cygnus.com>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00062.html
Content-length: 1192

> Jim> Yes.  It's my understanding that we can accomplish this with the
> Jim> gdbarch mechanism.
> 
> I was checking the rs6000/powerpc target (the other target I'm most
> familiar with), and NUM_REGS and REGISTER_BYTES are both set to the
> largest number for any powerpc varient.  There is no REGISTER_NAMES
> array, being replaced by a REGISTER_NAME() function which returns ""
> for registers not present for the selected varient.  This seems a 
> easy enough thing to do now before adding HAVE_FPU_REGS, etc. to
> derived target's tm-* headers.

I'm concerned about changing NUM_REGS for x86 targets which are not
actively maintained, or whose maintainers aren't participating in this
discussion.  I would like to be able to promise, "If you haven't
changed your target's code, then all the changes visible to your
configuration should be backwards-compatible."

I don't see how to do that without parameterizing the register file.
Perhaps the two parameters I chose --- HAVE_I387_REGS and
HAVE_SSE_REGS --- are not the best; perhaps simply something like
EXPANDED_I386_REGISTER_FILE, enabling the full set, would be better.

If you can see another way to deal with this, I'm all ears.
From jimb@cygnus.com Tue Oct 19 21:28:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: hjl@lucon.org (H.J. Lu)
Cc: gdb@sourceware.cygnus.com
Subject: Hardware watchpoints
Date: Tue, 19 Oct 1999 21:28:00 -0000
Message-id: <np3dv6k64w.fsf@zwingli.cygnus.com>
References: <19991019235249.917DC1B494@ocean.lucon.org>
X-SW-Source: 1999-q4/msg00063.html
Content-length: 625

> My Linux gdb has supports for ...
> 2. "better" x86 hw watchpoint. It is different from the normal x86
> hw watchpoint which I don't like.

I wonder, would it be possible to watch expressions like foo.x by
having can_use_hardware_watchpoint ignore lval_memory values which are
still lazy?  If a value is lazy, that means GDB never actually fetched
it, but instead just used its address.

Evaluating the expression foo.x, I think, produces two values: one for
'foo', which is lazy, and a second for the '.x' member of the first
value, which is no longer lazy.

This would remove the need for part of H.J.'s change, I think.
From Peter.Schauer@regent.e-technik.tu-muenchen.de Wed Oct 20 01:40:00 1999
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: capveg@cs.umd.edu (Rob)
Cc: gdb@sourceware.cygnus.com, capveg@cs.umd.edu
Subject: Re: fix to noexec_user_stack on solaris 2.{6,7}
Date: Wed, 20 Oct 1999 01:40:00 -0000
Message-id: <199910200839.KAA17702@reisser.regent.e-technik.tu-muenchen.de>
References: <199910192229.SAA04909@xor.cs.umd.edu>
X-SW-Source: 1999-q4/msg00064.html
Content-length: 1835

This will break calling of functions that return a structure or union.

As per sparc calling conventions the call must looks like this:

        call fun,0
        nop
        unimp <size of returned struct>

Setting CALL_DUMMY_LOCATION to AT_ENTRY_POINT doesn't handle this case.

When I was looking at the problem a long time ago, I had no idea how to
solve it properly.

> [Initial apologies if this has been dealt with.  I wasn't able
> to find a FAQ, and a searches for "noexec" and "user stack" turned 
> up nothing]
> 
> Hi,
> 
> I recently started running my solaris 2.6 boxes with the
> noexec_user_stack option that prevents anyone from executing code
> off of the data segment of a process.  This is a great security
> feature, and has been relatively painless.  I ran into a problem
> with the gdb feature "call" and "print proc()", but seem to
> have gotten around it by putting:
> 
> #define CALL_DUMMY_LOCATION          AT_ENTRY_POINT
> #define CALL_DUMMY_ADDRESS()         entry_point_address ()
> 
> at the end of gdb-4.18/gdb/config/sparc/tm-sun4sol2.h
> 
> So my questions are:
> 	- has someone already fixed this, and I have a shiny new wheel?
> 	- is this a proper fix?  I have read only enough of the gdb code
> 			to get this working...
> 	- does this break anything else my limited tests
> 		haven't found?
> 	- would it be possible/advisable to get a ./configure
> 		option of "--non-executable-data-stack" to
> 		enable this?  I know linux has a similar patch
> 		to turn of the user stack, so this is useful
> 		for other architectures.
> 
> Assuming I am on the right track, I can submit a patch.  I
> just wanted to get some sanity checks first :)~
> 
> TIA, and for what its worth, gdb is a great program, so thanks!
> 
> 
> - Rob
> .
> 
> 
> 
> 


-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From eliz@gnu.org Wed Oct 20 06:47:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Wed, 20 Oct 1999 06:47:00 -0000
Message-id: <199910201347.JAA28369@mescaline.gnu.org>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00065.html
Content-length: 7053

Sorry for the late start, but you guys caught me off-guard: this issue
lays dormant for such a long time that I began reading the messages
once every other day, then every third day...

Anyway, these comments are only by inspection of Jim's patch for now
(I will try to actually build GDB with these changes later this week):

1) Comment no.1:

+ #define FIRST_FPU_CTRL_REGNUM 24
+ #define FCTRL_REGNUM 24	        /* FPU control word */
+ #define FPC_REGNUM   24		/* old name for FCTRL_REGNUM */
+ #define FSTAT_REGNUM 25		/* FPU status word */
+ #define FTAG_REGNUM  26		/* FPU register tag word */
+ #define FCS_REGNUM   27		/* FPU instruction's code segment selector

Why does this define an old name for the FP control register, but not
for the rest?  If back-compatibility (a Good Idea, IMHO), then let's
be consistent.  tm-go32.h has these:

#define FPCWD_REGNUM FPC_REGNUM
#define FPSWD_REGNUM 25		/* 80387 status register */
#define FPTWD_REGNUM 26		/* 80387 tag register */
#define FPIPO_REGNUM 29		/* 80387 instruction pointer offset reg */
#define FPIPS_REGNUM 27		/* 80387 instruction pointer selector reg */
#define FPOOS_REGNUM 30		/* 80387 operand pointer offset reg */
#define FPOPS_REGNUM 28		/* 80387 operand pointer selector reg */

However, if DJGPP is the only platform which defines anything beyond
FPC_REGNUM, then we may stop bothering about the rest (DJGPP itself
doesn't use any of the rest, even though they are defined).

2) Comment no.2:
  
! #define REGISTER_VIRTUAL_TYPE(N)				\
!   (((N) == PC_REGNUM || (N) == FP_REGNUM || (N) == SP_REGNUM)	\
!    ? lookup_pointer_type (builtin_type_void)			\
!    : IS_FP_REGNUM(N) ? builtin_type_double			\
!    : IS_SSE_REGNUM(N) ? builtin_type_v4sf			\
!    : builtin_type_int)

Why are FP registers treated as type `double'?  x87 uses long double,
not double, and tm-go32.h says this:

#define REGISTER_VIRTUAL_TYPE(N) \
  ((N < FP0_REGNUM) ? builtin_type_int : \
   (N < FPC_REGNUM) ? builtin_type_long_double : builtin_type_int)

i386-tdep.c clearly uses 10 bytes when it initializes
i386_register_byte[], so I gather that other x86 targets also support
the full 80-bit width of FP registers, right?  Don't we want all the
80 bits in "info float"?

3) Comment no.3:

! 
! #define REGISTER_CONVERT_TO_VIRTUAL(REGNUM,TYPE,FROM,TO)	\
! {								\
!   double val;							\
!   i387_to_double ((FROM), (char *)&val);			\
!   store_floating ((TO), TYPE_LENGTH (TYPE), val);		\
! }

Same here: long double is not supported.

Also, if REGISTER_CONVERTIBLE(REGNUM) is zero, you could simply use
memcpy, it is faster.

This also applies to REGISTER_CONVERT_TO_RAW.

4) Several comments to Jim's message and the discussion that ensued:

  Jim> Since we're doing our own layout, we have the opportunity to set
  Jim> aside the weird packing used by the FSAVE instruction, and have the
  Jim> registers hold something more meaningful.  Thus, I've split out the
  Jim> instruction segment selector and the opcode bits, previously
  Jim> different bitfields of the $fcs register, into two separate
  Jim> registers.

I think we need to discuss this a bit.  Please note that the FP
registers are printed by GDB in two different ways: one is with the
command "info float", the other with "info all-registers".  I agree
that "info float" should present the information in a manner suitable
for debugging numerical code, i.e., the opcode should be separated
from the instruction selector, and its missing 5 bits should be added
to the printed value; but I think that "info all-registers" should
print the registers *exactly* as the CPU stores them.

Of course, this comment is only relevant to how we _print_ the
registers, not how we maintain them internally.

  Jim> The instruction (code) segment and offset are $fcs and $fcoff.
  Jim> The data operand       segment and offset are $fds and $fdoff.

I suggest $fcseg and $fcoff, $fdseg and $fdoff, instead.  People who
work a lot with seg:off pairs will recofnise `seg', but not `s'.

  Jim> I have not included support for the MMX or 3DNow! registers.
  Jim> [...]  I want to leave taht for a separate discussion.

I agree that MMX etc. is a separate problem.  I would think that they
deserve a separate command, e.g. "info mmx", just like the FP
registers do.

(FWIW, the DJGPP debug infrastructure already supports MMX, it just
isn't exposed to GDB, since GDB doesn't yet know about MMX.)

  Jim> We could make the control registers (except $fdoff and $fcoff)
  Jim> sixteen-bit values.  But that makes more work for platforms that do
  Jim> use FSAVE's 32-bit format; I assume those are the majority.

AFAIK, FSAVE does use 32 bits to store the control, status and tag
words, but the high 16 bits are undefined.  Isn't it dangerous to copy
all 32 bits to GDB's structures?  The DJGPP version doesn't copy the
high 16 bits from the buffer stored by FSAVE; if other platforms do
that as well, we already have, in effect, 16-bit control registers.

  Mark> For now, GDB on the Hurd will happily display what's in the
  Mark> reserved bits that follow the control, status, and tag word
  Mark> and the operand pointer segment selector in the data structure
  Mark> used by FSAVE and FRESTOR

I don't think this is right.  A user should see only the bits that are
defined by the CPU spec.  For all we know, the rest might be random
junk.

The DJGPP version displays 16 bits only for these registers.

  Jim> [...] the new SSE FXSAVE and FXRSTOR instructions save state in
  Jim> a different format, incompatible with FSAVE and FRSTOR, so
  Jim> either the OS interfaces will be changing, or the old ones will
  Jim> be emulated by code which changes from day to day.

There's another possibility: to use FXSAVE/FXRSTOR only for commands
that handle the SSE XMMi registers, and leave the current code for the
rest.  That way, we don't need to bother about reconciling the two
formats.

  Mark> So Intel has come up with yet another set of special purpose
  Mark> instructions that diddle with the floating point stuff?

Not only FXSAVE uses a different layout of the saved state, it also
does NOT perform the equivalent of FINIT.  In other words, it saves
the state without changing it, so you don't need to FXRSTOR right
after it, in case you need to preserve the state.

  Jim> I'm curious what Linux decides to do with the P-III support.

I'm confused--why is this relevant?  Are you talking about changes
that could affect how ptrace lays out the FP registers?  If not, what
do we care about Linux support of Pentium III?

  Mark> What remains to be written is the function that prints the
  Mark> output for the "info float" command.

  Jim> I'm easy to please here, but Eli Zaretskii had opinions on how
  Jim> this ought to work

I suggest to look at the thread we had discussing this back then.  If
memory serves, I posted a suggestion for the format of "info float",
based on Bill Metzenthen's code originally written for i387-tdep.c.

And let's not forget that "info all-registers" also prints the FP
registers, but in a different form.