Date: Fri, 23 Feb 2001 08:59:51 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Doug Rabson <dfr@nlsystems.com> Subject: Re: cvs commit: src/sys/alpha/alpha swtch.s Message-ID: <XFMail.010223085951.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0102231802020.8957-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010223085951.jhb>