From owner-freebsd-arch@FreeBSD.ORG Sat Dec 27 07:06:08 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F8C016A4CE for ; Sat, 27 Dec 2003 07:06:08 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D9F543D41 for ; Sat, 27 Dec 2003 07:06:05 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [10.0.0.2] (herring.nlsystems.com [10.0.0.2]) hBRF5rwO005231; Sat, 27 Dec 2003 15:05:53 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1072537553.1143.19.camel@herring.nlsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 27 Dec 2003 15:05:53 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on herring.nlsystems.com cc: arch@freebsd.org Subject: Re: sigaltstack with threads X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2003 15:06:08 -0000 On Sat, 2003-12-27 at 14:56, Daniel Eischen wrote: > On Sat, 27 Dec 2003, Doug Rabson wrote: > > > I've been using my festive spare time in porting the excellent valgrind > > error checker to FreeBSD. While working through the complex way that > > valgrind deals with signals, I noticed a tricky problem. > > > > When a signal stack is installed in FreeBSD, the stack location is > > recorded in the per-process state (p_sigstk to be exact). This stack is > > used in sendsig() for signals handlers which asked for SA_ONSTACK. This > > is a problem for valgrind since it uses two threads (I use the thr_* > > syscalls for this purpose). > > > > The main thread does most of the work and wants to take a selection of > > signals (SIGSEGV, SIGBUS etc) on a signal stack allocated for the > > purpose - all other signals are blocked. > > > > The other thread is used for executing blocking syscalls (actually there > > can be more than one of these for pthread programs but I don't have that > > working yet). This syscall thread runs with something like the debugged > > program's normal signal mask so most of those signals get routed to the > > syscall thread. The main problem is that the syscall thread wants to > > take the signals on its normal stack but it can't use a different > > setting for sigaltstack. > > > > It seems to me that sigaltstack needs to be per-thread state, not > > per-process state otherwise it is essentially useless for threaded > > programs. As far as I can make out, this is the behaviour for Linux > > threads created using their clone syscall. > > In the '96 POSIX spec, using sigaltstack() in threaded applications > was undefined. The new (SUSv3 200[123]?) POSIX spec allows this > but says "Use of this function by library threads that are not bound > to kernel-scheduled entities results in undefined behavior". I think > that allows you to make it per-thread, but what behavior do we > want when there are multiple threads in a KSE/KSEG? Should it be > per KSE or KSEG? I think that if its supported at all in threaded programs, it must be per-thread state otherwise you can't prevent two different threads colliding on the same signal stack. I can't quite see how this maps to KSE/KSEG since I only have the most hazy model of that stuff in my head right now. Anyway, I've worked around things by not setting SA_ONSTACK for the handlers that I want to run on the thread stack.