From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Mon, 21 Feb 2005 10:41:06 -0500 From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Questions about libthread and setjmp In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Topicbox-Message-UUID: 11f96098-ead0-11e9-9d60-3106f5b1d025 > t->sched[JMPBUFSP] = (ulong)tos - 8; /* old PC and new PC */ Taking this as a concrete example, the thread library is trying to make it look like launcher386(f, arg) called setjmp at the very beginning of its execution. If it had, the stack would look like: arg f pc of caller of launcher386 ("old pc") pc of caller of setjmp (== launcher386, "new pc") and the saved SP is the one pointing at the bottom of this stack. When longjmp comes along, it restores SP to the same place, writes the jmp_buf PC over the slot marked "pc of caller of setjmp" (in normal setjmp/longjmp use that memory word is no longer valid) and executes a return instruction, ending up at the beginning of launcher386 with f, arg as the arguments on the stack. Normal setjmp-produced stacks look a little different, because there is a pointer to the jump buffer, and perhaps then a stack frame full of local variables, between the two pcs. But here we are not returning to a function that has called setjmp. We are "returning" to the beginning of a function, so we want the stack to look like it does on entry, not like it does in the middle. Russ