From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25196 invoked by alias); 3 May 2010 22:57:23 -0000 Received: (qmail 25186 invoked by uid 22791); 3 May 2010 22:57:21 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,TW_GJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 May 2010 22:57:16 +0000 Received: (qmail 8520 invoked from network); 3 May 2010 22:57:15 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 May 2010 22:57:15 -0000 Date: Mon, 03 May 2010 22:57:00 -0000 From: Daniel Jacobowitz To: Richard Earnshaw Cc: Matthew Gretton-Dann , gdb-patches@sourceware.org Subject: Re: [PATCH/ARM] Fix support of longjmp for ARM Linux. Message-ID: <20100503225712.GA8410@caradoc.them.org> References: <1272547868.19716.13.camel@e102111-lin.cambridge.arm.com> <1272548983.28096.23.camel@e102346-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1272548983.28096.23.camel@e102346-lin.cambridge.arm.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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-05/txt/msg00058.txt.bz2 On Thu, Apr 29, 2010 at 02:49:43PM +0100, Richard Earnshaw wrote: > > On Thu, 2010-04-29 at 14:31 +0100, Matthew Gretton-Dann wrote: > > Hi, > > > > Can someone please review and comment on the attached patch? > > > > The patch fixes support for longjmp on ARM Linux. Dependent on the FP > > model in use the location of the PC to use as the long jump return value > > is stored in different locations in the long jump buffer. Currently gdb > > uses a hard-coded value which works for only one FP model, this patch > > corrects this. I'm not going to make a fuss, but for the record I am very weakly opposed to this patch. The offset of PC in the longjmp buffer is deliberately left implementation-private by the EABI. I'd rather we got back to the generic (step-based or breakpoint-based rather than jmp_buf-decoding-based) solution to longjmp.exp failures. On the other hand, I can't see why this should hurt :-) -- Daniel Jacobowitz CodeSourcery