From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: jimb@cygnus.com Cc: hjl@valinux.com, gdb@sourceware.cygnus.com Subject: Re: x86 fpu Date: Tue, 19 Oct 1999 16:43:00 -0000 Message-id: <199910192343.BAA00273@delius.kettenis.local> References: <19991019182843.E7C093FC1@valinux.com> X-SW-Source: 1999-q4/msg00060.html From: Jim Blandy 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 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: References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.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 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: 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" 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 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 To: Jim Blandy 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> <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.