From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17699 invoked by alias); 30 Aug 2011 09:11:21 -0000 Received: (qmail 17690 invoked by uid 22791); 30 Aug 2011 09:11:19 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Aug 2011 09:10:59 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7U9Ax3m001328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 30 Aug 2011 05:10:59 -0400 Received: from zebedee.pink (ovpn-116-19.ams2.redhat.com [10.36.116.19]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p7U9Auwx001401; Tue, 30 Aug 2011 05:10:58 -0400 Message-ID: <4E5CA920.5040003@redhat.com> Date: Tue, 30 Aug 2011 09:11:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Thunderbird/3.1.12 MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Re: ARM Linux EABI: unwinding through a segfault handler References: <4E563F58.2060006@redhat.com> <4E5BADCC.4060809@linaro.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg00446.txt.bz2 On 08/29/2011 06:13 PM, Daniel Jacobowitz wrote: > On Mon, Aug 29, 2011 at 11:18 AM, Ken Werner wrote: >> On 08/25/2011 02:26 PM, Andrew Haley wrote: >>> >>> Throwing an exception through a segfault handler doesn't always work >>> on ARM: the attached example fails on current gcc trunk. >>> >>> panda-9:~ $ g++ segv.cc -fnon-call-exceptions -g >>> panda-9:~ $ ./a.out >>> terminate called after throwing an instance of 'FoobarException*' >>> Aborted >>> >>> The bug is that _Unwind_GetIPInfo doesn't correctly set ip_before_insn. >>> Instead, it always sets it to zero; it should be set to 1 if this >>> is a frame created by a signal handler: >>> >>> >>> #define _Unwind_GetIPInfo(context, ip_before_insn) \ >>> (*ip_before_insn = 0, _Unwind_GetGR (context, 15)& ~(_Unwind_Word)1) >>> >>> >>> Fixing this on ARM is hard because signal frames aren't specially >>> marked as they are on systems that use DWARF unwinder data. I have >>> a patch that works on systems where the signal restorer is exactly >>> >>> mov r7, $SYS_rt_sigreturn >>> swi 0x0 >>> >>> It works as a proof of concept, but it's fugly. >>> >>> So, suggestions welcome. Is there a nice way to detect a signal frame? >> >> Libunwind also reads the IP to detect signal frames on ARM Linux: >> http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=blob;f=src/arm/Gis_signal_frame.c;hb=HEAD >> >> I'd also be interested if there are better approaches to detect them. :) > > There aren't better ways - this is pretty much the standard for > on-stack signal frames :-) > > I thought we used a handler in GLIBC that was properly annotated, > nowadays, but I might be mistaken. We don't for ARM, and indeed we can't. ARM unwind frames don't have any way of encoding the fact that they're signal frames or AFAICS of encoding the return address offset. Andrew.