From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67406 invoked by alias); 23 May 2019 14:35:59 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 67398 invoked by uid 89); 23 May 2019 14:35:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?Yes, score=8.7 required=5.0 tests=BAYES_80,BODY_8BITS,GARBLED_BODY,HTML_MESSAGE,PYZOR_CHECK,RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.3.1 spammy==e7=b3=bb=e4=ba=ba=ef=bc, =e5=be=ae=e4=bf=a1=e5, =b0=e4=bc, =b0=e6=ad=a3=e8=a7?= X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 May 2019 14:35:58 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33594) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTop2-00086H-0e for gdb@sourceware.org; Thu, 23 May 2019 10:35:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39636) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hTooy-0002Cq-12 for gnu-gdb-bug@gnu.org; Thu, 23 May 2019 10:35:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hToox-00082X-9U for gnu-gdb-bug@gnu.org; Thu, 23 May 2019 10:35:51 -0400 Received: from [115.216.42.187] (port=50429 helo=lmpl.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hToou-0007tX-Ut for gnu-gdb-bug@gnu.org; Thu, 23 May 2019 10:35:51 -0400 Received: from SKY-20150219JSJ ([127.0.0.1]) by localhost via TCP with ESMTPA; Thu, 23 May 2019 22:29:19 +0800 MIME-Version: 1.0 From: scwhr To: gnu-gdb-bug@gnu.org Date: Thu, 23 May 2019 14:43:00 -0000 Subject: =?utf-8?B?KioqKirnqI4qKioqKuelqCoqKioq?= X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 Message-ID: X-Received-From: 115.216.42.187 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-SW-Source: 2019-05/txt/msg00039.txt.bz2 JmFtcDsmYW1wOyZhbXA7JmFtcDsmYW1wOyZhbXA7JmFtcDsmYW1wOyZhbXA7 JmFtcDsmYW1wOyZhbXA7JmFtcDsmYW1wOyZhbXA7JmFtcDsmYW1wOyZhbXA7 JmFtcDsmYW1wOyZhbXA7JmFtcDsmYW1wOyZhbXA7JmFtcDsmYW1wOyZhbXA7 JmFtcDsmYW1wOyZhbXA7JmFtcDsmYW1wOyZhbXA7JmFtcDsmYW1wOyZhbXA7 JmFtcDsmYW1wOw0K5byA5ZCE5Zyw5q2j6KeE5pmu6YCa56iO56Wo77yM54K5 5pWw5LyY5oOg77yM5YyF55yf44CCDQrogZTns7vkurrvvJrlvKDlhYjnlJ8x MzktNTQ0My04OTYx77yI5b6u5L+h5ZCM5Y+377yJDQror6bnlLXvvJrkuJrl iqFRUe+8mjI2NDkzMTIyMDlnbnUtZ2RiLWJ1Z2dudS1nZGItYnVnQGdudS5v cmcNCiZuYnNwOw== >From gdb-return-47017-listarch-gdb=sources.redhat.com@sourceware.org Thu May 23 14:43:19 2019 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 83988 invoked by alias); 23 May 2019 14:43:19 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Delivered-To: mailing list gdb@sourceware.org Received: (qmail 83980 invoked by uid 89); 23 May 2019 14:43:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_05,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=gdb.execute, *runningthreadid, gdbexecute, *stopped,reason X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 May 2019 14:43:17 +0000 Received: from [172.16.0.120] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 47E6C1E481; Thu, 23 May 2019 10:43:15 -0400 (EDT) Subject: Re: GDB/MI executing a python command To: David Griffiths , GDB References: From: Simon Marchi Message-ID: <6dd959f2-09cf-2bb2-45cd-0f945ae5409d@simark.ca> Date: Thu, 23 May 2019 14:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-05/txt/msg00040.txt.bz2 Content-length: 2450 On 2019-05-22 8:37 a.m., David Griffiths wrote: > Hi, I have a GDB/MI front-end and would like to execute a GDB Python > extension command. This command will then in turn issue a number of > gdb.execute commands itself (for reasons to do with storing state, it is > potentially easier this way than issuing multiple MI commands). I expected > that when I run gdb.execute with "to_string=True" that all the output would > be captured. But this is not the case - lots of stuff gets output on the MI > channel. For instance doing a stepi I get: > > ^running > *running,thread-id="all" > ~"0x00007ff54501f1f5 in ?? ()\n" > *stopped,reason="end-stepping-range",frame={addr="0x00007ff54501f1f5",func="??",args=[]},thread-id="2",stopped-threads="all" > > this is in addition to the captured gdb.execute reply. > > Is there a way to disable this additional MI output whilst my command is > running? Or maybe a better way of doing this? > > Thanks, > > David > Hi David, First of all, I must warn that issuing execution control commands (run, continue, step, etc) in some particular context (e.g. in a breakpoint's stop method) is known to be problematic. There should really be a good way to control the execution from Python, but there isn't as of today. If this works for your use case, then great, but know that is an unpaved road. Second, I think that at least some of this output is expected and there's no way I know of disabling it. The ones starting with "*" and "~" are expected, because they asynchronous output sent to all UIs to propagate information about state changes, not just the one UI issuing the command. I am unsure about the "^running" though. When I type "stepi" in an MI interpreter, I get "^running", that's perhaps acceptable. But in your case, the "stepi" from gdb.execute("stepi") should not be executed by an MI interpreter, but by a CLI interpreter (I believe). So your "stepi" shouldn't produce an MI response. And even if it was correct to reply with ^running, it should probably end up in the returned string, as it is a direct response/output of your command, not asynchronous output. Finally, I am not sure what your use case is, but this patch series that is currently in review might interest you: https://sourceware.org/ml/gdb-patches/2019-05/threads.html#00313 It allows to implement MI commands in Python, allowing those commands to return proper MI output that is consumed by the frontend. Simon