From owner-cvs-all Fri Feb 23 9: 0:56 2001 Delivered-To: cvs-all@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 7450E37B503; Fri, 23 Feb 2001 09:00:48 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f1NH0WK24766; Fri, 23 Feb 2001 09:00:32 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f1NGxpj74856; Fri, 23 Feb 2001 08:59:51 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 23 Feb 2001 08:59:51 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Bruce Evans Subject: Re: cvs commit: src/sys/alpha/alpha swtch.s Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Doug Rabson Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Feb-01 Bruce Evans wrote: > On Thu, 22 Feb 2001, John Baldwin wrote: > >> On 22-Feb-01 Doug Rabson wrote: >> > On Thu, 22 Feb 2001, John Baldwin wrote: >> >> Oops, bit too hasty. There is one remaining MD portion in the alpha >> >> ast() that the ia64 ast() has inherited, we set the p->p_md.md_tf field >> >> to point to the trapframe passed in to ast(). Do you know what it is >> >> used >> >> for? >> > >> > Its used in various places to get at the original trapframe which we >> > entered the kernel with. This is needed for instance in signal delivery >> > and execve handling. The i386 equivalent is p_md.md_regs. >> > >> > I'm not sure how the i386 code gets away without setting md_regs. Perhaps >> > its always set correctly be whatever happened right before the call to >> > ast(). > > At least on i386's, it would be a bug to call ast() with any frame other > than the original trap frame or equivalent. ast() can only be called > when the stack has been unwound to the original frame. The registers > are in that frame. p_md.md_registers is just a pointer to the registers > in that frame, for use in subroutines where the original frame is not > directly accessible. Yes, which is why we didnt' actually destroy anything. Duh. *smacks forehead* I was bothered that things hadn't been blowing up all over the place. Since we only call ast() from userland, it the 'sp' for the frame would be more or less a constant address on curproc's kernel stack. > On i386's, it always has the same value (a fixed amount below the top > of the process's kernel stack). Setting it more than once per process > is pessimal. Not setting it in ast() usually works because there was > a previous syscall or trap that set it. Note that there is no bug in > old versions that multiplexed ast() through() trap(). Interrupt > handlers were turned into trap handlers before they called ast(), and > trap() set md_regs. Interrupt handlers still have a slightly different > frame from trap handlers, so setting md_regs for them doesn't even > make sense until they become trap handlers and call ast(). Well, should he hackishly set it in vm_fork() or cpu_fork() rather than bothering to set it for traps, syscalls, and ast's? Do you know if the same would be true (it being a fixed address) on other archs. It would seem that any arch that used separate stacks for kernel and user would do this.. > Bruce -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message