Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: Thiago Jung Bauermann <bauerman@br.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: Eliminate tui_command_loop
Date: Fri, 05 Aug 2011 12:37:00 -0000	[thread overview]
Message-ID: <201108051337.07646.pedro@codesourcery.com> (raw)
In-Reply-To: <4E3B0358.6000307@br.ibm.com>

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:
> >   <http://sourceware.org/ml/gdb/2005-01/msg00064.html>
> 
> 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 volatile
> 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) <www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

"7.13.2.1 The longjmp function
All accessible objects have values, and all other components of the abstract 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 containing the
invocation of the corresponding setjmp macro that do not have volatile-qualified 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.

-- 
Pedro Alves


  parent reply	other threads:[~2011-08-05 12:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-04 20:11 Pedro Alves
2011-08-04 20:18 ` Tom Tromey
2011-08-05 13:02   ` Pedro Alves
2011-08-05 15:11     ` Tom Tromey
2011-08-04 20:39 ` Thiago Jung Bauermann
2011-08-05  3:49   ` Sergio Durigan Junior
2011-08-05 12:37   ` Pedro Alves [this message]
2011-09-10 12:51 ` Matt Rice
2011-09-10 16:52   ` Matt Rice
2011-09-10 18:47   ` Pedro Alves
2011-09-11  0:46     ` Matt Rice
2011-09-11 14:41       ` Matt Rice
2011-09-13  8:29         ` PR gdb/13175 (Re: Eliminate tui_command_loop) Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201108051337.07646.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=bauerman@br.ibm.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox