public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Simon Sobisch <simonsobisch@gnu.org>
To: GDB Mailing list <gdb@sourceware.org>
Subject: How to loop in python extension while accepting mi-commands?
Date: Thu, 10 Mar 2022 20:40:39 +0100	[thread overview]
Message-ID: <38452700-d8b8-88cd-ed4d-8fcda89b29ac@gnu.org> (raw)

I've created an auto-step command (something like that in-built would be 
quite nice), both the "easy" and "nearly full" implementation can be 
found with some explanation at https://stackoverflow.com/a/67470615/5027456


At its core the command does:
         # recognize the kind of stop via stop_handler_auto_step
         global last_stop_was_simple
         last_stop_was_simple = True

         # actual auto-stepping
         try:
             while last_stop_was_simple:
                 gdb.execute("step")
                 time.sleep(sleep_time)
         # we just quit the loop as requested
         # pass keyboard and user errors unchanged
         except (KeyboardInterrupt, gdb.GdbError):
             raise

with a handler of

def stop_handler_auto_step(event):
     # check the type of stop, the following is the common one after
     # step/next, a more complex one would be a subclass (for example
     # breakpoint or signal)
     global last_stop_was_simple
     if not type(event) is gdb.StopEvent:
         last_stop_was_simple = False



This works in general on the console, steps with a pause as setup and 
you can follow the code execution.


It stops on breakpoints and other "events" and when issuing CTRL-C the 
code receives the KeyboardInterrupt and is stopped, too.


The problem with this code: while an application can send 
-exec-interrupt 10 times GDB seems to queue that because the 
user-command is still active.

After the loop is ended, for example by a breakpoint, the MI-side 
receives 10 times a "done" response - so there's more than guessing that 
GDB seems to queue the commands.


I've tried to move the loop into a python thread via 
"thread.start_new_thread(loop_func(sleep_time)" and while the stepping 
worked the -exec-interrupt was still not received.


Side note:
gdb (in this case 9.2 but similar was seen in newer versions) was 
started with "-iex set pagination off -iex set mi-async on".



Questions:
* Is there a way to accept mi-commands while running in Python extension 
in general?
* Is there a better approach for the auto-step than a loop like the one 
above, ending depending on KeyboardInterrupt or a gdb event happens?
* Is there any chance that a command like can be added into GDB? If yes: 
would it be helpful to send the "full" python extension script to 
gdb-patches?


Thanks for any comments,
Simon

                 reply	other threads:[~2022-03-10 19:40 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38452700-d8b8-88cd-ed4d-8fcda89b29ac@gnu.org \
    --to=simonsobisch@gnu.org \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).