This is the mail archive of the 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]

Re: [PATCH 2/4]: Handle SIGINT under Python by raising KeyboardInterrupt

>>>>> "Yit" == Khoo Yit Phang <> writes:

Yit> I don't know GDB's code base well enough to know if there are commands
Yit> that can affect signal handling in subsequent commands

I don't think there are any; at least, the only SIGINT changes I see
seem to be local.

Yit> If so, then gdb.execute("handle SIGINT print") should preserve the
Yit> handler. This is the "safer" behavior, that's my reasoning.

Yeah.  One concern I have with this approach is that, if it is not
needed, then it can be confusing for future maintainers.

Yit> If I understand correctly, you're thinking of how to handle Ctrl-C
Yit> that occurs in a Python context that should be treated as an interrupt
Yit> in an outer GDB context, right? I think rather than setting quit_flag
Yit> in the signal handler, we can catch KeyboardInterrupt after "python"
Yit> returns, then set quit_flag there.

What I'd like to do, ideally, is make it so that when in a "gdb
context", gdb-style SIGINT processing is done; and when in a "Python
context", python-style is done.

The issue with auditing TRY_CATCH uses and only augmenting the "slow"
ones is that the rest of gdb changes; loops and calls to QUIT are added;
but it will be difficult to remember to update the Python layer.

I'm thinking now that we should perhaps have paired macros like:

#define PY_ENTER_GDB \
  {  struct cleanup *try_cleanup = use_gdb_signals();

#define PY_LEAVE_GDB \
     do_cleanups (try_cleanup); }

Then just bracket all existing TRY_CATCH calls in python/*.c with those.
Then this can just be a rule for future hacking on the python layer.

But it seems if we are going to do that we could go a bit further:

sig_atomic_t in_gdb;

#define PY_ENTER_GDB \
  { in_gdb = 1;

#define PY_LEAVE_GDB \
  gdb_check_quit_flag (); }

Then have the signal handler we install for Python code do:

  if (in_gdb)
     quit_flag = 1;
     PyErr_SetInterrupt ();

... and finally, have 

void gdb_check_quit_flag (void)
  in_gdb = 0;
  if (quit_flag)
      PyErr_SetInterrupt ();
      quit_flag = 0;


This seems simple and efficient to me.
It also does not seem racy, though I'd appreciate a double-check.


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