From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id A28F13858D39 for ; Thu, 10 Mar 2022 19:40:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A28F13858D39 Received: from [2001:470:142:3::e] (port=33870 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nSOeS-0000T1-2y for gdb@sourceware.org; Thu, 10 Mar 2022 14:40:44 -0500 Received: from ip5f5a87b5.dynamic.kabel-deutschland.de ([95.90.135.181]:55738 helo=[192.168.111.41]) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nSOeQ-0000pV-LN for gdb@sourceware.org; Thu, 10 Mar 2022 14:40:43 -0500 Message-ID: <38452700-d8b8-88cd-ed4d-8fcda89b29ac@gnu.org> Date: Thu, 10 Mar 2022 20:40:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Content-Language: en-US To: GDB Mailing list From: Simon Sobisch Subject: How to loop in python extension while accepting mi-commands? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2022 19:40:46 -0000 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