Re: Remote protocol tune up...

[Todd Whitesel <toddpw@wrs.com>]

> regard to ``(256*1024)'', foke law has it that some hosts do not handle
> alloca()s larger than 64k.  If you're going to allow large transfers
> then it will need to avoid alloca().''

Alloca really should not be used for stuff that is going to get arbitrarily
large. Many people have their stacksize limit at 8 megs or so, and some of
the NetBSD ports (arm32, pc532, vax) have their default hard limit set at
8 megs also. (Not sure why they felt it necessary to do this; it may have
been an attempt to avoid something nasty in the VM hardware.)

It has been noted that linking large programs (think mozilla) can cause GNU
ld to alloca() quite a bit, ultimately using more than 8 megs of stack.

<soapbox>
I recall being repulsed by the concept of alloca() when I first heard of it.
It really is a gruesome hack just to avoid leaking memory when you get an
error. But if you have any other kind of cleanup to do, alloca() is no help.
</soapbox>

-- 
Todd Whitesel
toddpw @ wrs.com
From ac131313@cygnus.com Thu Oct 14 17:05:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: William Gatliff <gatliff@haulpak.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: Remote protocol tune up...
Date: Thu, 14 Oct 1999 17:05:00 -0000
Message-id: <38066F6A.FD7AD5EB@cygnus.com>
References: <3805B369.464A948C@cygnus.com> <3805CD64.3A2AA33D@haulpak.com>
X-SW-Source: 1999-q4/msg00029.html
Content-length: 1386

William Gatliff wrote:
> 
> Andrew:
> 
> >         comments, complaints?
> 
> Not sure I follow everything you suggested, but I'm no gdb-internals guru
> by far...
> 
> Just make sure the maximum packet size is clearly and easily
> configurable--- lots of targets don't even have a few hundred bytes of
> contiguous memory in which to store an incoming gdb packet...

Yes, definitly. That is last thing on my mind :-)

At present the remote protocol determines the size of the largest packet
based on MIN(sizeof registers_packet, ``remote packet-size - a small
number'').  That will remain the default behavour.

I'm looking to:

	o	maximize the size of that packet (within
		the bounds imposed by the remote target).

		What happens at present is that generic_load
		requests N transfers of 256 bytes say, but then
		a lower layer (remote_write_bytes()) breaks that
		256 byte chunk into two packets of ~240 and ~16
		bytes :-(.
		
		The proposed change will see remote_write_bytes()
		transfer a 240 byte packet and then return to
		generic_load() which can then top things up and
		issue a brand new transfer request.

	O	allow the user to maximize the size of each
		packet (almost) lifting all the arbitrary bounds.

		When the target's buffer is huge and the bandwidth
		almost infinite there is little point in transfering
		things in little 256 byte chunks :-)
	
enjoy,
	Andrew
From jtc@redback.com Thu Oct 14 17:43:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: Remote protocol tune up...
Date: Thu, 14 Oct 1999 17:43:00 -0000
Message-id: <5memex8ndk.fsf@jtc.redbacknetworks.com>
References: <3805B369.464A948C@cygnus.com>
X-SW-Source: 1999-q4/msg00030.html
Content-length: 1212

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> * generic_load()

Andrew> (Ignoring the bug fixes) This function will be changed to use
Andrew> target_write_memory_partial(). This allows the code to
Andrew> re-charge each transfer attempt to the maximum allowable
Andrew> (according to the chunk size).  The GENERIC_LOAD_CHUNK will
Andrew> also be replaced by a run-time variable that even allows
Andrew> chunking to be disabled.  I'll also bump GENERIC_LOAD_CHUNK up
Andrew> to 512 (2*512 + header/footer <= sizeof (udp packet)), any
Andrew> bids for 1024?

Umm, just how are you computing sizeof(udp packet)?  I count 20 bytes
for a IP packet without any options plus 8 for the UDP header for a
zero length UDP packet.  Not that this matters much...

A logical refinement of your proposal would be to do target write size
discovery.  Instead of having generic_load() attempt to write N bytes,
target_write_memory() return an indication that M bytes were actually
written, 're-chargeing' the transfer by adding N-M bytes of data, and
then attempting to write an N byte buffer again; I believe it should
drop back to using an M byte write.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Thu Oct 14 19:01:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Todd Whitesel <toddpw@wrs.com>, Stan Shebs <shebs@cygnus.com>
Cc: GDB Developers <gdb@sourceware.cygnus.com>
Subject: Re: Remote protocol tune up...
Date: Thu, 14 Oct 1999 19:01:00 -0000
Message-id: <38068AC1.11A914F@cygnus.com>
References: <199910142159.OAA09943@alabama.wrs.com>
X-SW-Source: 1999-q4/msg00031.html
Content-length: 2277

Todd Whitesel wrote:
> 
> > regard to ``(256*1024)'', foke law has it that some hosts do not handle
> > alloca()s larger than 64k.  If you're going to allow large transfers
> > then it will need to avoid alloca().''
> 
> Alloca really should not be used for stuff that is going to get arbitrarily
> large. Many people have their stacksize limit at 8 megs or so, and some of
> the NetBSD ports (arm32, pc532, vax) have their default hard limit set at
> 8 megs also. (Not sure why they felt it necessary to do this; it may have
> been an attempt to avoid something nasty in the VM hardware.)

Some history is probably in order:

The original remote.c code had compile time PBUFSIZE constant and that
was used to allocate scratch buffers on the stack vis:

	  char buf[PBUFSIZE];

Since PBUFSIZE is small (for all known cases :-) the operation was
reasonably safe.

Then multi-arch arrived and the assumption that PBUFSIZE (based on
REGISTER_BYTES) was constant went out the window.  Fortunatly it was
still small so, the pragmatic decision was to convert the array's into
alloca() (1):

	char *buf = alloca (PBUFSIZE);

(Looking through remote.c I notice that several array style declarations
have crept back in - GCC accepts them ...).

The current proposal (and thanks to IA64 a reflection of the new
reality) is to remove the assumption that PBUFSIZE is small.  Doing this
involves xmalloc() and (*!&^#(*@!#) cleanups and incremental changes
(JimB you are not allowed to talk about GUILE :-)


As for alloca(). It stinks.  Unfortunatly it is a reliable mechanism for
allocating small arbitrary sized data that has a well defined lifetime. 
GDB typically uses a cleanup when creating a data structure that should
out live the current function;s lifetime but, if an error occures,
should be re-claimed.  Alloca gets used when the programmer knew that
the data's lifetime was determined by that of the bounding function.

Before this goes any further I think I'll just mention that it was a
Nazi that made me do it :-)
( http://www.wins.uva.nl/~mes/jarg320.old/g/GodwinsLaw.html )

	enjoy,
		Andrew



(1) If you look through the code you'll notice that multi-arch
introduced several other alloca()s but again where it was known that the
buffer involved while dynamic was small.
From ac131313@cygnus.com Thu Oct 14 21:10:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: Remote protocol tune up...
Date: Thu, 14 Oct 1999 21:10:00 -0000
Message-id: <3806A8FE.7B0ABC2D@cygnus.com>
References: <3805B369.464A948C@cygnus.com> <5memex8ndk.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00032.html
Content-length: 1922

"J.T. Conklin" wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> Andrew> * generic_load()
> 
> Andrew> (Ignoring the bug fixes) This function will be changed to use
> Andrew> target_write_memory_partial(). This allows the code to
> Andrew> re-charge each transfer attempt to the maximum allowable
> Andrew> (according to the chunk size).  The GENERIC_LOAD_CHUNK will
> Andrew> also be replaced by a run-time variable that even allows
> Andrew> chunking to be disabled.  I'll also bump GENERIC_LOAD_CHUNK up
> Andrew> to 512 (2*512 + header/footer <= sizeof (udp packet)), any
> Andrew> bids for 1024?
> 
> Umm, just how are you computing sizeof(udp packet)?  I count 20 bytes
> for a IP packet without any options plus 8 for the UDP header for a
> zero length UDP packet.  Not that this matters much...

I'm a computer scientist, I count in powers of two :-)
(The 2*512 is what the M packet does to 512 bytes of data. The X
packet's worse case is the same.

> A logical refinement of your proposal would be to do target write size
> discovery.  Instead of having generic_load() attempt to write N bytes,
> target_write_memory() return an indication that M bytes were actually
> written, 're-chargeing' the transfer by adding N-M bytes of data, and
> then attempting to write an N byte buffer again; I believe it should
> drop back to using an M byte write.

Don't forget that the size of each write isn't predictable - an X packet
might need to expand one M byte chunk to 2*M bytes (everything escaped)
while the next goes straight through.  You're never absolutly certain
how much will get transfered at each attempt :-)

The other obvious question would be: what is GENERIC_LOAD_CHUNK for? It
puts an absolute cap on the download chunk size. This (simplisticly)
ensures that a UI has a look in on the process so that it can detect
things like a request to abort the transfer.

	enjoy,
		Andrew
From jimb@cygnus.com Fri Oct 15 10:16:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Unifying the x86 FPU register sets
Date: Fri, 15 Oct 1999 10:16:00 -0000
Message-id: <199910151716.MAA03441@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00033.html
Content-length: 11417

I'd like to restart the discussion we had over the summer about
getting GDB's machine-level x86 FPU support in shape.

In an attempt to understand how the current tm-*.h files are actually
arranged, I put together a little diagram to help confuse, er, clarify
the issue:

http://sourceware.cygnus.com/gdb/papers/linux/i386-includes.gif

Among the seven header files that do define FP regs, there's general
chaos:
- tm-i386.h and tm-cygwin.h don't name the control registers.
- tm-linux.h puts control regs first, while tm-go32.h puts them last,
  and they use different names.
- tm-sun386.h does everything altogether differently.  (But uses the
  same control register names as tm-go32.h!)
- tm-ptx.h and tm-symmetry.h don't provide the control registers,
  but they do provide a second FPU.

There's also general chaos amongst the various *-nat.c files about
what "info float" prints.  It seems that each OS implements the
command differently.  i387-tdep.c contains some shared code for
printing FPU status and control words, but that's it.  This is kind of
lame.  They all have the same FPU, and use it in the same way, after
all.

So, our goals are:
- eliminate the meaningless diversity in FPU register names
- turn i387-tdep.c into full-featured support for displaying i387
  status, in a way that can be shared by the various x86 targets.

I propose making the register file section of tm-i386.h, from which
everyone inherits, read as shown below.  Given this, we can write an
i387-tdep.c that actually has some meat to it.  Some comments:

- The idea here is to provide a common base for everyone to use.  If
  you see things that are inappropriate for your target, say so, and
  let's figure out the best way to handle it.

- If you see anything unclear or ambiguous, please say so.  Each
  register's meaning should be completely specified.  It should be
  completely obvious how each target should fill in the register file.
  It won't do us any good if everybody does it slightly differently.

- I've got Linux working using this text, but it's still highly
  experimental.  Please read with a critical eye.

- Since there are a lot of configurations that use the register info in
  tm-i386.h unmodified (see the diagram), and not all of those
  platforms have maintainers participating in this discussion, we may
  only change tm-i386.h in backwards-compatible ways.

- In particular, we may only add new register names onto the end; we
  may not insert new registers or rearrange existing ones.  This
  precludes having the FP register file match the layout used by the
  x86 FSAVE/FRSTOR instructions, in which the control registers
  precede the FP registers.  But this isn't such a tragedy, since the
  SSE FXSAVE / FXRSTOR instructions use a different format too, so
  what consensus might have existed before is somewhat broken already.

- Thus, the way the FP control registers are laid out here probably
  does not match the arrangement used by any kernel, bit-for-bit.  You
  can't just use a memcpy to fill in a register set.  Everyone will
  need to write code to convert between the format in which their OS
  provides the registers, and GDB's format as described below.  Most
  platforms do this already anyway.

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

  GDB's job is to present information to the user in a helpful way, so
  I think this is appropriate.  Since we're processing the bits
  received from the kernel anyway, this isn't a real burden.

- I've changed the names of some of the FP control registers, to
  better reflect their meanings.  I think the names are more
  consistent than the old names, but please speak up if you disagree.

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

- I've included support for the SSE registers.  So the code below
  refers to things that aren't in GDB yet, but will be in the next few
  days.

- I have not included support for the MMX or 3DNow! registers.  Since
  they're superimposed on the FPU registers, it's not clear how best
  to provide access to them.  I want to leave that for a separate
  discussion.




/* This register file is parameterized by two macros:
   HAVE_I387_REGS --- register file should include i387 registers
   HAVE_SSE_REGS  --- register file should include SSE registers
   If HAVE_SSE_REGS is #defined, then HAVE_I387_REGS must also be #defined.
   
   However, GDB code should not test those macros with #ifdef, since
   that makes code which is annoying to multi-arch.  Instead, GDB code
   should check the values of NUM_GREGS, NUM_FREGS, and NUM_SSE_REGS,
   which will eventually get mapped onto architecture vector entries.

   It's okay to use the macros in tm-*.h files, though, since those
   files will get completely replaced when we multi-arch anyway.  */

/* Number of general registers, present on every 32-bit x86 variant.  */
#define NUM_GREGS (16)

/* Number of floating-point unit registers.  */
#ifdef HAVE_I387_REGS
#define NUM_FREGS (16)
#else
#define NUM_FREGS (0)
#endif

/* Number of SSE registers.  */
#ifdef HAVE_SSE_REGS
#define NUM_SSE_REGS (9)
#else
#define NUM_SSE_REGS (0)
#endif

#define NUM_REGS (NUM_GREGS + NUM_FREGS + NUM_SSE_REGS)

/* Largest number of registers we could have in any configuration.  */
#define MAX_NUM_REGS (16 + 16 + 9)

/* Initializer for an array of names of registers.  There should be at least
   NUM_REGS strings in this initializer.  Any excess ones are simply ignored.
   The order of the first 8 registers must match the compiler's numbering
   scheme (which is the same as the 386 scheme) and also regmap in the various
   *-nat.c files. */

#define REGISTER_NAMES { "eax",   "ecx",    "edx",   "ebx",	\
			 "esp",   "ebp",    "esi",   "edi",	\
			 "eip",   "eflags", "cs",    "ss",	\
			 "ds",    "es",     "fs",    "gs",	\
			 "st0",   "st1",    "st2",   "st3",	\
			 "st4",   "st5",    "st6",   "st7",	\
			 "fctrl", "fstat",  "ftag",  "fcs",	\
                         "fcoff", "fds",    "fdoff", "fop",	\
			 "xmm0",  "xmm1",   "xmm2",  "xmm3",	\
			 "xmm4",  "xmm5",   "xmm6",  "xmm7",	\
                         "mxcsr"				\
		       }

/* Register numbers of various important registers.
   Note that some of these values are "real" register numbers,
   and correspond to the general registers of the machine,
   and some are "phony" register numbers which are too large
   to be actual register numbers as far as the user is concerned
   but do serve to get the desired values when passed to read_register.  */

#define FP_REGNUM 5		/* (ebp) Contains address of executing stack
				   frame */
#define SP_REGNUM 4		/* (usp) Contains address of top of stack */
#define PC_REGNUM 8		/* (eip) Contains program counter */
#define PS_REGNUM 9		/* (ps)  Contains processor status */

/* These registers are present only if HAVE_I387_REGS is #defined.
   We promise that FP0 .. FP7 will always be consecutive register numbers.  */
#define FP0_REGNUM   16		/* first FPU floating-point register */
#define FP7_REGNUM   23		/* last  FPU floating-point register */

#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
				   16 bits, called "FPU Instruction Pointer
				   Selector" in the x86 manuals  */
#define FCOFF_REGNUM 28		/* FPU instruction's offset within segment
				   ("Fpu Code OFFset") */
#define FDS_REGNUM   29		/* FPU operand's data segment */
#define FDOFF_REGNUM 30		/* FPU operand's offset within segment */
#define FOP_REGNUM   31		/* FPU opcode, bottom eleven bits */
#define LAST_FPU_CTRL_REGNUM 31

/* These registers are present only if HAVE_SSE_REGS is #defined.
   We promise that XMM0 .. XMM7 will always have consecutive reg numbers. */
#define XMM0_REGNUM  32		/* first SSE data register */
#define XMM7_REGNUM  39		/* last  SSE data register */
#define MXCSR_REGNUM 40		/* Streaming SIMD Extension control/status */

#define IS_FP_REGNUM(n) (FP0_REGNUM <= (n) && (n) <= FP7_REGNUM)
#define IS_SSE_REGNUM(n) (XMM0_REGNUM <= (n) && (n) <= XMM7_REGNUM)

#define FPU_REG_RAW_SIZE (10)

/* Sizes of individual register sets.  */
#define SIZEOF_GREGS (NUM_GREGS * 4)
#define SIZEOF_FPU_REGS (8 * FPU_REG_RAW_SIZE)
#define SIZEOF_FPU_CTRL_REGS \
  ((LAST_FPU_CTRL_REGNUM - FIRST_FPU_CTRL_REGNUM + 1) * 4)
#define SIZEOF_SSE_REGS (8 * 16 + 4)


/* Total amount of space needed to store our copies of the machine's register
   state, the array `registers'. */
#ifdef HAVE_SSE_REGS
#define REGISTER_BYTES \
  (SIZEOF_GREGS + SIZEOF_FPU_REGS + SIZEOF_FPU_CTRL_REGS + SIZEOF_SSE_REGS)
#else
#ifdef HAVE_I387_REGS
#define REGISTER_BYTES (SIZEOF_GREGS + SIZEOF_FPU_REGS + SIZEOF_FPU_CTRL_REGS)
#else
#define REGISTER_BYTES (SIZEOF_GREGS)
#endif
#endif

/* Index within `registers' of the first byte of the space for register N. */
#define REGISTER_BYTE(n) (i386_register_byte[(n)])
extern int i386_register_byte[];

/* Number of bytes of storage in the actual machine representation for
   register N.  */
#define REGISTER_RAW_SIZE(n) (i386_register_raw_size[(n)])
extern int i386_register_raw_size[];

/* Largest value REGISTER_RAW_SIZE can have.  */
#define MAX_REGISTER_RAW_SIZE 16

/* Number of bytes of storage in the program's representation
   for register N. */
#define REGISTER_VIRTUAL_SIZE(n) (i386_register_virtual_size[(n)])
extern int i386_register_virtual_size[];

/* Largest value REGISTER_VIRTUAL_SIZE can have.  */
#define MAX_REGISTER_VIRTUAL_SIZE 16

/* Return the GDB type object for the "standard" data type of data in 
   register N.  Perhaps si and di should go here, but potentially they
   could be used for things other than address.  */

#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)

/* REGISTER_CONVERTIBLE(N) is true iff register N's virtual format is
   different from its raw format.  Note that this definition assumes
   that the host supports IEEE 32-bit floats, since it doesn't say
   that SSE registers need conversion.  Even if we can't find a
   counterexample, this is still sloppy.  */
#define REGISTER_CONVERTIBLE(n) (IS_FP_REGNUM (n))

/* Convert data from raw format for register REGNUM in buffer FROM
   to virtual format with type TYPE in buffer TO.  */
extern void i387_to_double (char *, char *);

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

extern void double_to_i387 (char *, char *);

#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO)		\
{								\
  double val = extract_floating ((FROM), TYPE_LENGTH (TYPE));	\
  double_to_i387((char *)&val, (TO));				\
}
From kettenis@wins.uva.nl Fri Oct 15 11:43:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jimb@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Fri, 15 Oct 1999 11:43:00 -0000
Message-id: <199910151843.UAA05899@delius.kettenis.local>
References: <199910151716.MAA03441@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00034.html
Content-length: 2893

   Date: Fri, 15 Oct 1999 12:16:25 -0500 (EST)
   From: Jim Blandy <jimb@cygnus.com>

   I'd like to restart the discussion we had over the summer about
   getting GDB's machine-level x86 FPU support in shape.

Great!

   - The idea here is to provide a common base for everyone to use.  If
     you see things that are inappropriate for your target, say so, and
     let's figure out the best way to handle it.

I can see no problems that would make it impossible to adapt the Hurd
to use these definitions.

   - If you see anything unclear or ambiguous, please say so.  Each
     register's meaning should be completely specified.  It should be
     completely obvious how each target should fill in the register file.
     It won't do us any good if everybody does it slightly differently.

What's the meaning of `SIZEOF_FPU_CTRL_REGS' supposed to be?  Does it
imply that GDB will expects its `pseudo' FP control registers to be a
32bit value each?  Or will we allow REGISTER_RAW_SIZE(n) for the
control registers to be different from 4 for FIRST_FPU_CTRL_REGNUM <=
n <= LAST_FPU_CTRL_REGNUM ?  And will we allow different values for
different targets?  This affects the floating point status printing
routine of course, but I think it should be possible to write it such
that it can deal with such differences.

I think my life would be easier if all of them except FCOFF_REGNUM and
FDOFF_REGNUM would be 2 bytes long.  That makes it possible to use the
`memcpy approach' with the FSAVE layout that Mach uses to store the FP
state.

   - I've got Linux working using this text, but it's still highly
     experimental.  Please read with a critical eye.

I'll start working on Hurd support if I don't hear about objections
from other people soon.  Could you make the Linux code available
somehow?

   - Since there are a lot of configurations that use the register info in
     tm-i386.h unmodified (see the diagram), and not all of those
     platforms have maintainers participating in this discussion, we may
     only change tm-i386.h in backwards-compatible ways.

Is this why you kept FPC_REGNUM?  It should be possible to replace
FPC_REGNUM with FCTRL_REGNUM in all targets without breaking any of
them, and remove FPC_REGNUM completely.

   - In particular, we may only add new register names onto the end; we
     may not insert new registers or rearrange existing ones.  This
     precludes having the FP register file match the layout used by the
     x86 FSAVE/FRSTOR instructions, in which the control registers
     precede the FP registers.  But this isn't such a tragedy, since the
     SSE FXSAVE / FXRSTOR instructions use a different format too, so
     what consensus might have existed before is somewhat broken already.

I think you're right.  I was one of the people who suggested using the
FSAVE layout, but I think the layout you chose is much more elegant.

Mark
From jimb@cygnus.com Fri Oct 15 16:57:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Fri, 15 Oct 1999 16:57:00 -0000
Message-id: <npvh88kwic.fsf@zwingli.cygnus.com>
References: <199910151716.MAA03441@zwingli.cygnus.com> <199910151843.UAA05899@delius.kettenis.local>
X-SW-Source: 1999-q4/msg00035.html
Content-length: 2650

> I can see no problems that would make it impossible to adapt the Hurd
> to use these definitions.

Groovy.

>    - If you see anything unclear or ambiguous, please say so.  Each
>      register's meaning should be completely specified.  It should be
>      completely obvious how each target should fill in the register file.
>      It won't do us any good if everybody does it slightly differently.
> 
> What's the meaning of `SIZEOF_FPU_CTRL_REGS' supposed to be?  Does it
> imply that GDB will expects its `pseudo' FP control registers to be a
> 32bit value each?  Or will we allow REGISTER_RAW_SIZE(n) for the
> control registers to be different from 4 for FIRST_FPU_CTRL_REGNUM <=
> n <= LAST_FPU_CTRL_REGNUM ?  And will we allow different values for
> different targets?  This affects the floating point status printing
> routine of course, but I think it should be possible to write it such
> that it can deal with such differences.

There's more stuff in i386-tdep.c which makes the intent clearer ---
in particular, the i386_register_raw_size table is there.  See the
URL's below.

It would certainly be possible to allow the register sizes vary from
one platform to the next, and make sure i387-tdep.c relies entirely on
the macros and tables to do its job.  But to do that, we would need to
design the macros more carefully than I have --- I don't think they're
sufficient for the job right now.  I'd rather have them be fixed.

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


>    - I've got Linux working using this text, but it's still highly
>      experimental.  Please read with a critical eye.
> 
> I'll start working on Hurd support if I don't hear about objections
> from other people soon.  Could you make the Linux code available
> somehow?

Here is the full patch for all i386 architectures, including the
definitions for the raw register size arrays and such:
  http://www.cygnus.com/~jimb/jimb.i386-fp.patch

Here is my current patch for Linux:
  http://www.cygnus.com/~jimb/jimb.i386-linux-fp.patch

>    - Since there are a lot of configurations that use the register info in
>      tm-i386.h unmodified (see the diagram), and not all of those
>      platforms have maintainers participating in this discussion, we may
>      only change tm-i386.h in backwards-compatible ways.
> 
> Is this why you kept FPC_REGNUM?  It should be possible to replace
> FPC_REGNUM with FCTRL_REGNUM in all targets without breaking any of
> them, and remove FPC_REGNUM completely.

That's true.
From kettenis@wins.uva.nl Sat Oct 16 17:10:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jimb@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Sat, 16 Oct 1999 17:10:00 -0000
Message-id: <199910170010.CAA00525@delius.kettenis.local>
References: <199910151716.MAA03441@zwingli.cygnus.com> <199910151843.UAA05899@delius.kettenis.local> <npvh88kwic.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00036.html
Content-length: 1351

   From: Jim Blandy <jimb@cygnus.com>
   Date: 15 Oct 1999 18:57:31 -0500

   It would certainly be possible to allow the register sizes vary from
   one platform to the next, and make sure i387-tdep.c relies entirely on
   the macros and tables to do its job.  But to do that, we would need to
   design the macros more carefully than I have --- I don't think they're
   sufficient for the job right now.  I'd rather have them be fixed.

Actually I think they are fine, since I no longer see a reason for
different register sizes on different i386 platforms.

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

Although initially I thought I needed to use different register sizes
to implement things for exactly that format, I now see that I don't
need that.  The reserved bits are exactly in the right place to treat
it as an array of 32-bit values.  Only the code segment and opcode
registers need to be treated in a different way, as you did on the
Linux side.

A remaining issue is what we do with the reserved bits?  From looking
at your code, it seems that you allow the user to modify the reserved
bits (except for the reserved bit in the opcode word).  Is that a
sensible thing to do?

Mark
From jimb@cygnus.com Sun Oct 17 12:37:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Sun, 17 Oct 1999 12:37:00 -0000
Message-id: <npr9itlqwg.fsf@zwingli.cygnus.com>
References: <199910151716.MAA03441@zwingli.cygnus.com> <199910151843.UAA05899@delius.kettenis.local> <npvh88kwic.fsf@zwingli.cygnus.com> <199910170010.CAA00525@delius.kettenis.local>
X-SW-Source: 1999-q4/msg00037.html
Content-length: 1923

>    We could make the control registers (except $fdoff and $fcoff)
>    sixteen-bit values.  But that makes more work for platforms that do
>    use FSAVE's 32-bit format; I assume those are the majority.
> 
> Although initially I thought I needed to use different register sizes
> to implement things for exactly that format, I now see that I don't
> need that.  The reserved bits are exactly in the right place to treat
> it as an array of 32-bit values.  Only the code segment and opcode
> registers need to be treated in a different way, as you did on the
> Linux side.

Okay, sounds great then.

> A remaining issue is what we do with the reserved bits?  From looking
> at your code, it seems that you allow the user to modify the reserved
> bits (except for the reserved bit in the opcode word).  Is that a
> sensible thing to do?

I think we need to maintain a distinction between the GDB register
file and the structure the OS uses to exchange FPU state with the
debugger.  For GDB's register file, those are 16-bit registers,
zero-extended to make a 32-bit value.  (That should be stated in the
header file; I'll fix that.)  For the OS structure, it's up to the OS
to specify what those fields mean, and it's up to the OS-specific code
in GDB to do the right thing with the register file.  If some future
OS decides to put new registers there, then we should map them off to
new GDB registers.

This distinction isn't just pedantic, either --- the new SSE FXSAVE /
FXRSTOR instructions save state in a different format, incompatible
with FSAVE and FRSTOR, so either the OS interfaces will be changing,
or the old ones will be emulated by code which changes from day to
day.

I'm curious to see what Linux decides to do with the P-III support.  I
haven't looked at the Linux kernel patches yet to determine what new
ptrace interface they propose.  (Maybe I should post to the Linux
kernel mailing list.  Ooh boy.)
From kettenis@wins.uva.nl Sun Oct 17 14:57:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jimb@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Sun, 17 Oct 1999 14:57:00 -0000
Message-id: <199910172157.XAA00438@delius.kettenis.local>
References: <199910151716.MAA03441@zwingli.cygnus.com> <199910151843.UAA05899@delius.kettenis.local> <npvh88kwic.fsf@zwingli.cygnus.com> <199910170010.CAA00525@delius.kettenis.local> <npr9itlqwg.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00038.html
Content-length: 3074

   From: Jim Blandy <jimb@cygnus.com>
   Date: 17 Oct 1999 14:37:51 -0500

   >    We could make the control registers (except $fdoff and $fcoff)
   >    sixteen-bit values.  But that makes more work for platforms that do
   >    use FSAVE's 32-bit format; I assume those are the majority.
   > 
   > Although initially I thought I needed to use different register sizes
   > to implement things for exactly that format, I now see that I don't
   > need that.  The reserved bits are exactly in the right place to treat
   > it as an array of 32-bit values.  Only the code segment and opcode
   > registers need to be treated in a different way, as you did on the
   > Linux side.

   Okay, sounds great then.

I have it working now on the Hurd too.  I'll send a patch as soon as
I see your changes getting checked in.

What remains to be written is the function that prints the output for
the "info float" command based on the GDB register file.  If you
haven't done this already, I'm willing to give it a shot.  I should be
able to produce something useful by next weekend.

   > A remaining issue is what we do with the reserved bits?  From looking
   > at your code, it seems that you allow the user to modify the reserved
   > bits (except for the reserved bit in the opcode word).  Is that a
   > sensible thing to do?

   I think we need to maintain a distinction between the GDB register
   file and the structure the OS uses to exchange FPU state with the
   debugger.  For GDB's register file, those are 16-bit registers,
   zero-extended to make a 32-bit value.  (That should be stated in the
   header file; I'll fix that.)  For the OS structure, it's up to the OS
   to specify what those fields mean, and it's up to the OS-specific code
   in GDB to do the right thing with the register file.  If some future
   OS decides to put new registers there, then we should map them off to
   new GDB registers.

For now, GDB the Hurd will happily display what's in the reserved bits
that follow the control, status and tag word and the operand segment
selector in the data structure used by FSAVE and FRSTOR, but won't let
you change them.  If anybody complains I'll fill the reserved bits
with zeroes before loading them into the register file.

   This distinction isn't just pedantic, either --- the new SSE FXSAVE /
   FXRSTOR instructions save state in a different format, incompatible
   with FSAVE and FRSTOR, so either the OS interfaces will be changing,
   or the old ones will be emulated by code which changes from day to
   day.

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

   I'm curious to see what Linux decides to do with the P-III support.  I
   haven't looked at the Linux kernel patches yet to determine what new
   ptrace interface they propose.  (Maybe I should post to the Linux
   kernel mailing list.  Ooh boy.)

You can do it ... Just take a deep breath ... even I did that some
time ago.  It even resulted in two lines of MY code being added to the
kernel :-).

Mark