Chet Ramey <[email protected]> writes: > On 1/6/23 10:07 AM, Andrew Burgess wrote: >> Hi, >> >> While working on GDB, which uses the callback API, I've run into some >> issues relating to reverse isearch and signal handling. >> >> At the end of this email is a small example program that uses the >> callback API. This is a modified version of the example program that >> is included in the readline manual. >> >> The issue I have relies on a SIGINT arriving at just the wrong time. >> To reproduce this the test program uses rl_getc_function to setup a >> wrapper function (my_getc) that calls rl_getc. After a couple of >> times calling my_getc, a SIGINT is sent to the process using kill(). > > Two questions: what does gdb do when it gets the SIGINT? Readline sends it > back to the calling application. I assume it just sets a flag? And does > gdb set rl_signal_event_hook?
So, for SIGINT handling, I tried to kind-of model what GDB does in the demo program. [Any inaccuracies between actual GDB and my representation of it here are entirely my own fault.] But your guess is correct, GDB sets a flag and writes a single byte to a pipe file descriptor. When we return to GDB's main event loop, the pending read wakes our select, we then call the relevant sigint event handler. This then throws a C++ exception which is caught further up the stack, and we then redisplay the prompt using the rl_callback_handler_remove and rl_callback_handler_install calls that you can see in the demo program. The demo program skips the whole C++ exception part, but I think is an otherwise accurate representation of what GDB is doing. A grep on the GDB source tree indicates we don't set rl_signal_event_hook anywhere. I'll take a look now at the role that plays in this process and see if it will help at all, but I'd also welcome any insights you have. Thanks, Andrew
