aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/python.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2016-04-12 16:49:30 +0100
committerPedro Alves <palves@redhat.com>2016-04-12 16:55:16 +0100
commit4a81fd47b3052f4c1601f8eb7f7879b12e0473cd (patch)
tree814985bc78456d798faf70e518e4501431ebfce1 /gdb/python/python.c
parentabf009ef94d2f89b09767cce30bcf99224c1a0a9 (diff)
downloadbinutils-4a81fd47b3052f4c1601f8eb7f7879b12e0473cd.zip
binutils-4a81fd47b3052f4c1601f8eb7f7879b12e0473cd.tar.gz
binutils-4a81fd47b3052f4c1601f8eb7f7879b12e0473cd.tar.bz2
Don't call clear_quit_flag in command_handler
This just looks totally wrong to me, for completetly discarding a user-requested Ctrl-C. I can't think of why we'd want do this here. Actually, I digged the history, and found out that this has been here since at least 7b4ac7e1ed2c (gdb-2.4, the initial revision, 1988), at a time were we had a top level setjmp/longjmp, long before that got wrapped in throw_exception and friends, and this code was in an explicit loop, with the quit_flag cleared on every iteration, before executing a command... gdb/ChangeLog: 2016-04-12 Pedro Alves <palves@redhat.com> * event-top.c (command_handler): Don't call clear_quit_flag.
Diffstat (limited to 'gdb/python/python.c')
0 files changed, 0 insertions, 0 deletions