From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24901 invoked by alias); 6 Aug 2010 11:17:21 -0000 Received: (qmail 24888 invoked by uid 22791); 6 Aug 2010 11:17:19 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Aug 2010 11:17:14 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id o76BHA92016392 for ; Fri, 6 Aug 2010 13:17:10 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id o76BH8pM015284; Fri, 6 Aug 2010 13:17:08 +0200 (CEST) Date: Fri, 06 Aug 2010 11:17:00 -0000 Message-Id: <201008061117.o76BH8pM015284@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: gdb-patches@sourceware.org CC: gdb-patches@sourceware.org In-reply-to: <20100806104810.GJ4610@calimero.vinschen.de> (message from Corinna Vinschen on Fri, 6 Aug 2010 12:48:10 +0200) Subject: Re: [rfa] frame address size incorrect if address size != ptr size References: <20100805153010.GG4610@calimero.vinschen.de> <201008051651.o75GpmTo002448@d12av02.megacenter.de.ibm.com> <20100806104810.GJ4610@calimero.vinschen.de> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-08/txt/msg00061.txt.bz2 > Date: Fri, 6 Aug 2010 12:48:10 +0200 > From: Corinna Vinschen > > And... > > > It would then be interesting to see whether *both* .debug_frame and > > .eh_frame work on xstormy16 ... you might be able to try the latter > > by building with -fasynchronous-unwind-tables. > > ... .eh_frame sections are never generated for XStormy16. The > -fasynchronous-unwind-tables option is a no-op. Is there no C++ exception exception handling on XStormy16? Or did nobody bother to do the work of switching it away from setjump/longjump-style exception handling?