From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11928 invoked by alias); 31 Aug 2004 16:14:25 -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 11909 invoked from network); 31 Aug 2004 16:14:24 -0000 Received: from unknown (HELO palrel12.hp.com) (156.153.255.237) by sourceware.org with SMTP; 31 Aug 2004 16:14:24 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel12.hp.com (Postfix) with ESMTP id 1F3B4408B38; Tue, 31 Aug 2004 09:14:24 -0700 (PDT) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.13.1/8.13.1/HPL-PA Hub) with ESMTP id i7VGEKWL026318; Tue, 31 Aug 2004 09:14:21 -0700 (PDT) Received: from napali.hpl.hp.com (napali [127.0.0.1]) by napali.hpl.hp.com (8.12.11/8.12.11/Debian-3) with ESMTP id i7VGEKic029297; Tue, 31 Aug 2004 09:14:20 -0700 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.11/8.12.11/Debian-3) id i7VGEKbg029294; Tue, 31 Aug 2004 09:14:20 -0700 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16692.41948.53308.392397@napali.hpl.hp.com> Date: Tue, 31 Aug 2004 16:14:00 -0000 To: Ulrich Drepper Cc: davidm@hpl.hp.com, libc-hacker@sources.redhat.com, davidm@napali.hpl.hp.com Subject: Re: fix ia64 longjmp() to work from alternate signal-stack In-Reply-To: <413499B2.2030900@redhat.com> References: <16684.49335.802840.212013@napali.hpl.hp.com> <412DAC31.1050404@redhat.com> <16692.38122.52348.850833@napali.hpl.hp.com> <413499B2.2030900@redhat.com> Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-SW-Source: 2004-08/txt/msg00089.txt.bz2 >>>>> On Tue, 31 Aug 2004 08:30:58 -0700, Ulrich Drepper said: Uli> David Mosberger wrote: >> Were you able to get clarification on this issue already? Uli> Getting a formal answer will take a while. One reply I got indicated Uli> that indeed the altstack is not switched. So, the public siglongjmp Uli> interface need not handle this, just the exception handling stuff. If Uli> it turns out that we want the siglongjmp code to handle this as well Uli> some day, we still can enable it. For now, changing your patch to just Uli> implement the cancellation appropriately should go in. So you want me to create an ia64-specific version of __libc_longjmp() which will be sigaltstack-safe while everything else goes to the old longjmp implementation, right? The only callers of __libc_longjmp() I found are: ./linuxthreads/sysdeps/pthread/ptlongjmp.c: __libc_longjmp (env, val); ./nptl/sysdeps/pthread/pt-longjmp.c: __libc_longjmp (env, val); ./nptl/unwind.c: __libc_longjmp ((struct __jmp_buf_tag *) buf->cancel_jmp_buf, 1); ./nptl/unwind.c: __libc_longjmp ((struct __jmp_buf_tag *) ibuf->cancel_jmp_buf, 1); so I think this would have the desired effect. --david