This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Eliminate tui_command_loop
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