From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24670 invoked by alias); 26 Aug 2004 09:24:22 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 24638 invoked from network); 26 Aug 2004 09:24:22 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 26 Aug 2004 09:24:22 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7Q9OMS2011857 for ; Thu, 26 Aug 2004 05:24:22 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7Q9OH318930; Thu, 26 Aug 2004 05:24:17 -0400 Received: from [10.0.1.84] (drepper.cipe.redhat.com [10.0.1.84]) by lacrosse.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7Q9O7r30076; Thu, 26 Aug 2004 05:24:13 -0400 Message-ID: <412DAC31.1050404@redhat.com> Date: Thu, 26 Aug 2004 09:24:00 -0000 From: Ulrich Drepper Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040825 MIME-Version: 1.0 To: davidm@hpl.hp.com CC: libc-hacker@sources.redhat.com, davidm@napali.hpl.hp.com Subject: Re: fix ia64 longjmp() to work from alternate signal-stack References: <16684.49335.802840.212013@napali.hpl.hp.com> In-Reply-To: <16684.49335.802840.212013@napali.hpl.hp.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2004-08/txt/msg00073.txt.bz2 David Mosberger wrote: > If there are no objections, please apply this patch. I don't like this. The behavior of longjmp if the starting point is using the alternate stack while the destination uses the normal stack, is currently unspecified in POSIX. I've asked for clarification in the POSIX working group. The result I expect is "don't do it", aka, unspecified. So, this is no case the normal setjmp/longjmp needs to handle. For the unwind/cancellation handling this might not apply. But it is an implementation decision to use setjmp/longjmp. So, the solution should be to use special versions of those interfaces in the nptl implementation. For all platforms but ia64 the new names are just aliases of the normal code. For ia64 this heavier code is used. This will also take care of most of the performance penalties since they don't apply in general, only in the thread code. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖