From owner-freebsd-hackers Thu Jun 7 15: 1:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 04C5C37B405 for ; Thu, 7 Jun 2001 15:01:23 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA13329; Thu, 7 Jun 2001 18:00:41 -0400 (EDT) Date: Thu, 7 Jun 2001 18:00:41 -0400 (EDT) From: Daniel Eischen To: Stefan Hoffmeister Cc: Stefan Hoffmeister , freebsd-hackers@FreeBSD.ORG Subject: Re: libc_r, signal handler ucontext modification In-Reply-To: <4bdvhtgru1j77uvphko0dsg8ohpj8beloh@4ax.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Jun 2001, Stefan Hoffmeister wrote: > : On Thu, 7 Jun 2001 12:07:50 -0400 (EDT), Daniel Eischen wrote: > > >On Thu, 7 Jun 2001, Stefan Hoffmeister wrote: > > >> [copy context back into thread] > > >You can't do that. There is no requirement that the interrupted thread > >is the one that handles the signal. If you copy the context back to > >the current threads context storage, then you'll possibly end up with > >2 threads running (or trying to run) on the same stack! > > Ouch :-) > > >You could also easily modify the context and do a > >sigreturn(ucp) on it to achieve the same effect (being careful to make > >sure you're not trying to jump to another threads context). > > This sounds very good, indeed. I do not want to make a context switch; > essentially all I care about is that > > * the changed value of EIP is taken > > * ESP (from context) is retained > > * Changed values of EAX, EDX are taken > > AFA sigreturn is concerned: libc_r.so (!) does not export it; it only > exports _thread_sys_sigreturn. Is there some kind of "__strong_reference" > missing? > > In a slightly daring move, I am calling _thread_sys_sigreturn and, in my > trivial test scenario, this seems to work - now I wonder whether it is > supposed to work? > > IOW, is _thread_sys_sigreturn an alias for sigreturn in libc_r.so? Yeah, I don't know why sigreturn is hidden any longer. I don't think there's a need for it to be hidden. I suppose we could wrap it and check to make sure the thread performing the sigreturn isn't trying to return to a stack that isn't its own (like we do for siglongjmp/longjmp). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message