How to recognize `exec-interrupt` via Python events

How to recognize `exec-interrupt` via Python events

[Simon Sobisch]

It is possible that I've just overlooked something, but I can't seem to 
get an event triggered at all:

	gdb.events.stop.connect(stop_handler)

is triggered after each step/next, a expected; also on signals including 
SIGINT, also when pressing CTRL+C when the inferior is running, type can 
be checked with

	if type(event) is gdb.StopEvent

When the MI frontend (Vim in this case, but this should also apply to 
Emacs and others) executes `-exec-step` or `-exec-next` the event is 
triggered, when the inferior is running and a breakpoint/watchpint is 
triggered, too.
But when the inferior is running and `-exec-interrupt` is triggered then 
the python code seems to not get an event at all - do I need to connect 
to a different event registry?


The main _problem_ that this issue creates lies in the GDB python 
extension implementing an "auto-step" (starter code at [1]) and stopping 
when interrupted... but now I see that this does not work with clients 
that interrupt with `-exec-interrupt`, which _does_ stop the running 
process, but the python extension does not recognize it and steps 
further, so the interrupt is actually not working.


[1]: https://stackoverflow.com/a/67470758/5027456
Note: the new and better one catching more events and implementing a 
gdb.Parameter got lost there, I'll update that answerit when I know how 
to solve this issue.

Re: How to recognize `exec-interrupt` via Python events

[Andrew Burgess]

* Simon Sobisch via Gdb <gdb@sourceware.org> [2021-12-06 21:11:23 +0100]:

> It is possible that I've just overlooked something, but I can't seem to get
> an event triggered at all:
> 
> 	gdb.events.stop.connect(stop_handler)
> 
> is triggered after each step/next, a expected; also on signals including
> SIGINT, also when pressing CTRL+C when the inferior is running, type can be
> checked with
> 
> 	if type(event) is gdb.StopEvent
> 
> When the MI frontend (Vim in this case, but this should also apply to Emacs
> and others) executes `-exec-step` or `-exec-next` the event is triggered,
> when the inferior is running and a breakpoint/watchpint is triggered, too.
> But when the inferior is running and `-exec-interrupt` is triggered then the
> python code seems to not get an event at all - do I need to connect to a
> different event registry?

Maybe I'm not understanding your problem description, here's my
session trying to reproduce the issue:

##### START #####

$$$ cat test.c
#include <unistd.h>

int
main ()
{
  while (1)
    sleep (1);
  return 0;
}
$$$ gcc -g3 -O0 -o test.x test.c
$$$ cat stop-event.py 
import gdb

def stop_handler(event):
    print("stop event: %s" % event)

gdb.events.stop.connect(stop_handler)
$$$ gdb --version
GNU gdb (GDB) 11.1
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$$$ gdb -q -i mi test.x
=thread-group-added,id="i1"
=cmd-param-changed,param="print pretty",value="on"
~"Reading symbols from test.x...\n"
(gdb) 
-gdb-set mi-async on
^done
(gdb) 
source stop-event.py
&"source stop-event.py\n"
^done
(gdb) 
-exec-run
=thread-group-started,id="i1",pid="2623705"
=thread-created,id="1",group-id="i1"
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7fd3110",to="0x00007ffff7ff2bb4"}]
^running
*running,thread-id="all"
(gdb) 
=library-loaded,id="/lib64/libc.so.6",target-name="/lib64/libc.so.6",host-name="/lib64/libc.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7df36b0",to="0x00007ffff7f40c5f"}]
-exec-interrupt
^done
(gdb) 
~"\nProgram"
~" received signal SIGINT, Interrupt.\n"
~"0x00007ffff7e9c1e7 in nanosleep () from /lib64/libc.so.6\n"
*stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",frame={addr="0x00007ffff7e9c1e7",func="nanosleep",args=[],from="/lib64/libc.so.6",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="9"
~"stop event: <gdb.SignalEvent object at 0x7f6a502fcbd0>\n"
quit
&"quit\n"
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1"
$$$ 

##### END #####

Notice, the 6th line from the end of the session:

    ~"stop event: <gdb.SignalEvent object at 0x7f6a502fcbd0>\n"

This is the stop event arriving after the -exec-interrupt.  This was
with gdb 11.1, but I also tested 10.2, 9.2, and 8.3.1, all gave the
same results.

Could you provide an example .py file, and a precise sequence of MI
commands that reproduce the issue you're seeing.

Thanks,
Andrew