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

* Simon Sobisch via Gdb <[email protected]> [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