--------------650C506D3EF1BC26116B6F67
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi all,
First I want to appologize to all those I upset in my first note. I
clearly did not achieve the reaction I was looking for. I was hoping to
inspire one of you to make a quick fix to kernel assuming this was a no
brainer hack. But, that ain't gonna happen now...
So, let me start over. I really respect the things this group has done
for Linux. The only problem I've found is that fpu registers can't be
debugged. This is because ptrace doesn't support it. So, I'll post my
limited hack for your evaluation. I have a lot of FPU knowledge, but
little kernel experience. Let me know if you find any glaring problems
with the hack. Then, I'll post it to Linus.
First hack attempt:
Insert this code starting at line 394 in ptrace.c
if (hard_math) { /* for now skip fpu if using 387 emulator */
addr &= -4; /* align */
if (addr == &dummy->u_fpvalid) {
tmp = 1;
}
if (addr >= (long) &dummy->i387.cwd &&
addr <= (long) &dummy->i387.st_space[19]) {
__asm__("fnop"); /* forced dump of fpu state */
addr -= (long) &dummy->i387.cwd;
addr += (long) &child->tss.i387.hard.cwd;
tmp = *((long*) addr);
}
}
I haven't had a chance to compile this yet. Perhaps
I'll get to it during my lunch break. I have three questions about
this code. First, will the "hard_math" link (I hope so). Second,
is there a way in the kernel to tell if the child has used the
fpu or not. For now, I'm just assuming its always used, and I return
u_fpvalid as being true. Lastly, is there a better way to force a
fpu dump other than executing a fpu instruction in the current process.
I'm only adding code to read the state. I could
add code to write to the fpu state, but I don't want to risk putting a
security hole into the kernel. Thanks for your comments.
Regards,
Steve
-- Stephen Polkowski Centaur Technology Austin, TX (512) 418-5730--------------650C506D3EF1BC26116B6F67 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Received: from proxy.centtech.com (proxy.centtech.com [204.177.173.1]) by harley.centtech.com (8.8.4/8.6.9) with ESMTP id VAA19769 for <stephen@centtech.com>; Thu, 17 Jul 1997 21:31:24 -0500 (CDT) Received: (from smap@localhost) by proxy.centtech.com (8.8.4/8.6.9) id VAA17217 for <stephen@centtech.com>; Thu, 17 Jul 1997 21:36:37 -0500 (CDT) X-Authentication-Warning: proxy.centtech.com: smap set sender to <tytso@MIT.EDU> using -f Received: from pacific-carrier-annex.mit.edu(18.69.0.28) by proxy.centtech.com via smap (V2.0) id xma017211; Thu, 17 Jul 97 21:36:16 -0500 Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA20898; Thu, 17 Jul 97 22:35:30 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id WAA27661; Thu, 17 Jul 1997 22:36:45 -0400 Date: Thu, 17 Jul 1997 22:36:45 -0400 Message-Id: <199707180236.WAA27661@dcl.MIT.EDU> From: "Theodore Y. Ts'o" <tytso@MIT.EDU> To: Jason L Tibbitts III <tibbs@hpc.uh.edu> Cc: tiensivu@pilot.msu.edu, Stephen Polkowski <stephen@centtech.com>, Linux Kernel Digest <linux-kernel@vger.rutgers.edu> In-Reply-To: Jason L Tibbitts III's message of 17 Jul 1997 19:39:21 -0500, <ufawwmpb3d2.fsf@sina.hpc.uh.edu> Subject: Re: Linux and the lame FPU-ptrace function Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091
From: Jason L Tibbitts III <tibbs@hpc.uh.edu> Date: 17 Jul 1997 19:39:21 -0500
AT> Your knowledge exceeds your tact. If it weren't so condensending, I AT> would have loved to help.
Oh, come on. Now we're being overly sensitive. His question is very appropriate; why should he work on something if nobody cares about it enough to make use of it or if it has zero chance of making it into the kernel?
One of the problems that we're having is that the linux-kernel list is not necessarily sending out mail messages in order. I only received Stephen's message in its entirety long after Jason sent his rebuke to the list.
(This is one of the reasons why I always leave enough quoting in context so that everyone can understand my messages, because I know the mailings sometimes don't get sent out in order. For example, although I've seen bits and pieces of Linus's announcement of 2.1.45 quoted in other people's e-mail, I *still* haven't seen the original e-mail message. It's been much worse than usual lately; I wonder if it's related to the Internic's DNS screwup.)
Anyway, here's Stephen's original message as an example of how *not* to win friends and influence people.... It's another example of how we have far too many spoiled brats as users who don't realize that people work on Linux as a labor of love....
- Ted
>Date: Thu, 17 Jul 1997 10:09:40 -0500 >From: Stephen Polkowski <stephen@centtech.com> > > I've been using linux for about a year now >and I'm still amazed gdb still can't debug the simple >x86 fpu stack. If you don't believe me, type >"info float" under gdb. At first glance, you might >think that its just a gdb problem. It isn't. > > Linux doesn't support it, or rather, the >ptrace function doesn't support the dumping of the >fpu state. I can't imagine how Linux has evolved >without having a serious fpu debugger. Oh well. > > I really enjoy linux, so I've decided to fix >this problem. As it turns out, I discovered that a >"real" company called Absoft had to do their own kernel >hack for ptrace so that they could develop and debug >their Fortran product. This is unacceptible!!! Linux >needs to be real operating system with a real way >to debug it's fpu hardware state. > > So, I have the Absoft hack and I've looked >at the problem. The hack is not complete. It assumes that you have an >x86 fpu, so this would break on a >386 system. > > So, who wants to help me out, and how does one >get a patch into the official linux source code? Does >anyone really care about this? Thanks for your help.
--------------650C506D3EF1BC26116B6F67--