From owner-freebsd-arch Mon Oct 29 13: 0:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 57C0837B406; Mon, 29 Oct 2001 13:00:20 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA27026; Mon, 29 Oct 2001 12:58:22 -0800 (PST) Date: Mon, 29 Oct 2001 12:58:20 -0800 (PST) From: Julian Elischer To: Jake Burkholder Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: syscall() ABI questions In-Reply-To: <20011029151912.D14748@locore.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG But the API for vfork forbids the child from doing a 'ret' after the vfork returns.. if it does that, all bets are off.... you can do: vfork(); exec(); and that 's about all that's ok... I'm not even sure about vfork(); exit(); On Mon, 29 Oct 2001, Jake Burkholder wrote: > Apparently, On Mon, Oct 29, 2001 at 11:59:01AM -0800, > John Baldwin said words to the effect of; > > [...] > > > >> > > > >> > I think you're right about fork and rfork being able to use the MIASM > > >> > code. rfork with RFMEM is special but it can';t be safely called from > > >> > C anyway. The vfork wrapper needs to stay on x86 at least because both > > >> > processes return to the same stack; if the retunr address is not saved in > > >> > a register the child may clobber the parent's when it "rets" and pops > > >> > the stack. > > >> > > >> Same kernel stack? The register is set in the trapframe which means it is > > >> saved on the kernel stack. Is that shared in the vfork case? > > > > > > Same user stack. The trapframe is copied to the child's kernel stack. > > > > Then the vfork case should be fine, b/c we fixup %eax in the child's kernel > > stack so that when it returns from the syscall, %eax already has the right > > value. > > Sorry, maybe I wasn;t clear. The problem is that the parent's return > address can get clobbered unless its saved in a register and copied > through the trapframe. Otherwise if the child returns from the kernel > and immediately executes a "ret", the parent's return address will be > below %esp on the shared stack and could get clobbered. It uses > jmp *%ecx now to return, which works fine because both parent and > child have a _copy_ of the value. > > I hope this makes sense :) > > > > > -- > > > > 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 freebsd-arch" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message