This is the mail archive of the gdb-testers@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[binutils-gdb] Don't call clear_quit_flag in prepare_to_throw_exception


*** TEST RESULTS FOR COMMIT 0af679c6e0645a93d5a60ec936b94dc70a2f9e5c ***

Author: Pedro Alves <palves@redhat.com>
Branch: master
Commit: 0af679c6e0645a93d5a60ec936b94dc70a2f9e5c

Don't call clear_quit_flag in prepare_to_throw_exception

I think this is reminiscent of the time when a longjmp would always
jump to the top level.  Nowaways code that throw exceptions other than
a quit, which may even be caught and handled without reaching the top
level.  Certainly such exceptions shouldn't clear an interrupt
request...

(We also need to get rid of prepare_to_throw_exception in order to be
able to just do "throw ex;" in C++.)

One could argue that we should clear the quit flag when we throw a
quit from the SIGINT handler, when immediate_quit is in effect, to
handle a race, here:

 immediate_quit++;
 QUIT;

... that's the usual pattern code must use when enabling
immediate_quit.  The QUIT is there to catch the case of Ctrl-C having
already been pressed before immediate_quit was enabled.  However, this
can happen:

 immediate_quit++;
<< Ctrl-C pressed here too.
 QUIT;

And in that case, if the quit flag was already set, it'll stay set
even after throwing a quit from the SIGINT handler.  The end result is
a double quit.  But OTOH, the user did press Ctrl-C two times.  Since
I'm getting rid of immediate_quit, I'm not bothering with this.

gdb/ChangeLog:
2016-04-12  Pedro Alves  <palves@redhat.com>

	* exceptions.c (prepare_to_throw_exception): Don't clear the quit
	flag.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]