From mboxrd@z Thu Jan 1 00:00:00 1970 From: Todd Whitesel To: ac131313@cygnus.com (Andrew Cagney) Cc: gdb@sourceware.cygnus.com (GDB Developers) Subject: Re: Remote protocol tune up... Date: Thu, 14 Oct 1999 14:59:00 -0000 Message-id: <199910142159.OAA09943@alabama.wrs.com> References: <3805B369.464A948C@cygnus.com> X-SW-Source: 1999-q4/msg00028.html > 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. 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. -- Todd Whitesel toddpw @ wrs.com >From ac131313@cygnus.com Thu Oct 14 17:05:00 1999 From: Andrew Cagney To: William Gatliff Cc: GDB Discussion 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 Cc: GDB Discussion 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 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 To: Todd Whitesel , Stan Shebs Cc: GDB Developers 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 To: jtc@redback.com Cc: GDB Discussion 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 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 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 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 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 To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: Unifying the x86 FPU register sets Date: Fri, 15 Oct 1999 16:57:00 -0000 Message-id: 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 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> X-SW-Source: 1999-q4/msg00036.html Content-length: 1351 From: Jim Blandy 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 To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: Unifying the x86 FPU register sets Date: Sun, 17 Oct 1999 12:37:00 -0000 Message-id: References: <199910151716.MAA03441@zwingli.cygnus.com> <199910151843.UAA05899@delius.kettenis.local> <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 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> <199910170010.CAA00525@delius.kettenis.local> X-SW-Source: 1999-q4/msg00038.html Content-length: 3074 From: Jim Blandy 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