From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31531 invoked by alias); 5 Aug 2011 12:37:59 -0000 Received: (qmail 31434 invoked by uid 22791); 5 Aug 2011 12:37:57 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_GJ,TW_TJ 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; Fri, 05 Aug 2011 12:37:16 +0000 Received: (qmail 20409 invoked from network); 5 Aug 2011 12:37:15 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Aug 2011 12:37:15 -0000 From: Pedro Alves To: Thiago Jung Bauermann Subject: Re: Eliminate tui_command_loop Date: Fri, 05 Aug 2011 12:37:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <201108042110.45405.pedro@codesourcery.com> <4E3B0358.6000307@br.ibm.com> In-Reply-To: <4E3B0358.6000307@br.ibm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201108051337.07646.pedro@codesourcery.com> X-IsSubscribed: yes 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: 2011-08/txt/msg00106.txt.bz2 On Thursday 04 August 2011 21:38:48, Thiago Jung Bauermann wrote: > On 08/04/2011 05:10 PM, Pedro Alves wrote: > > which predates TRY_CATCH by a few years: > > >=20 > Since you brought the subject: I noticed a while ago that there are some > places which declare the exception variable used in TRY_CATCH without > the volatile keyword. At the time I changed all such occurrences to volat= ile > but there was no effect in the testsuite so I didn't bother submitting the > patch upstream. Is this important? Yes, because GDB exceptions are implemented on top of setjmp/longjmp. >From N1256 (c99+tc1+tc2+tc3) "7.13.2.1 The longjmp function All accessible objects have values, and all other components of the abstrac= t machine have state, as of the time the longjmp function was called, except that the= values of objects of automatic storage duration that are local to the function contai= ning the invocation of the corresponding setjmp macro that do not have volatile-qual= ified type and have been changed between the setjmp invocation and longjmp call are indeterminate. " setjmp/longjmp are implemented by saving/restoring registers. Without volatile, a compiler would be free to put the local exception object in a register or registers instead of on stack memory. Since longjmp restores registers to the state they had at setjmp time, we'd lose changes to the exception object done between setjmp and longjmp. --=20 Pedro Alves