From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113256 invoked by alias); 19 Jan 2017 14:31:34 -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 112127 invoked by uid 89); 19 Jan 2017 14:31:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=marc, H*Ad:U*bob, HTo:U*bob, multi X-HELO: sesbmg22.ericsson.net Received: from sesbmg22.ericsson.net (HELO sesbmg22.ericsson.net) (193.180.251.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Jan 2017 14:31:23 +0000 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id CA.FC.15498.8BDC0885; Thu, 19 Jan 2017 15:31:20 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 19 Jan 2017 15:31:55 +0100 Received: from DB4PR07MB0656.eurprd07.prod.outlook.com (10.141.44.148) by DB4PR07MB0654.eurprd07.prod.outlook.com (10.141.44.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Thu, 19 Jan 2017 14:30:59 +0000 Received: from DB4PR07MB0656.eurprd07.prod.outlook.com ([10.141.44.148]) by DB4PR07MB0656.eurprd07.prod.outlook.com ([10.141.44.148]) with mapi id 15.01.0860.012; Thu, 19 Jan 2017 14:30:58 +0000 From: Marc Khouzam To: Bob Rossi , "gdb@sourceware.org" Subject: Re: GDB/MI questions Date: Thu, 19 Jan 2017 14:31:00 -0000 Message-ID: References: <20170119031445.GA24616@xubuntu.brasko.net> In-Reply-To: <20170119031445.GA24616@xubuntu.brasko.net> authentication-results: spf=none (sender IP is ) smtp.mailfrom=marc.khouzam@ericsson.com; x-ms-office365-filtering-correlation-id: 5c775a18-6ff6-41a4-73cb-08d44077c961 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB0654; x-microsoft-exchange-diagnostics: 1;DB4PR07MB0654;7:XmMWI6hjnTaG53bACC9DZDjBJxp8+8dXnYr9+lCEPdCHgSKKTjrcn72OBY/R+xc7lcPgo1AyoKXkNI6XU1fYK1/Rk7uoZrinheyQc7Q/H7Yx0Ayt9M7Ny5WzRaslP9sdjM1xTsMSf9Xgqqgie0RsbuiHdA1kk6OR/9q2tBamMAMwFbjcEojlcypJHmF6QAkJyUBgwPUN8TK5zytaTYKw5g4Jz+3UxqQnTOU2JElVYcM1Cci5b43qvUSZ+3th3y9GDTCeFy7zwttXW2uCF6UKFoHDQHcUAWlaZcD9jKVW1Sl3llSmB11Cf5n+NmDAnM+HIB4sNlBlvnccZPSKwCg8R5jGL2ykQBp7oVnmkj+zz8WxRv6hnuZFNr9b3KPcmctpa28QZzx2+HeKdGMqc+yQGSVtNege7R4eLQyQ66J5ilvtw+CIoJq4D1wv86GFcEEUlmsDuA0MbfrP2DwgoiE/Rg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123558021)(20161123555025)(20161123564025)(6072148);SRVR:DB4PR07MB0654;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB0654; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(53484002)(199003)(469094003)(92566002)(53936002)(5660300001)(122556002)(6506006)(7736002)(6436002)(105586002)(38730400001)(99286003)(66066001)(68736007)(55016002)(305945005)(102836003)(77096006)(2950100002)(2906002)(106356001)(6116002)(7696004)(33656002)(106116001)(8676002)(3480700004)(81156014)(81166006)(8936002)(229853002)(76176999)(97736004)(54356999)(101416001)(86362001)(107886002)(3280700002)(74316002)(2501003)(50986999)(25786008)(3846002)(3660700001)(9686003)(5001770100001)(189998001)(2900100001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB4PR07MB0654;H:DB4PR07MB0656.eurprd07.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2017 14:30:58.8412 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB0654 X-OriginatorOrg: ericsson.com X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00029.txt.bz2 > Hi, >=20 > I'm attempting to convert CGDB (a GDB front end) from annotations to MI. > Two questions I've run up against: >=20 > The first is, with annotations, it's easy to tell when GDB can except > another command, just wait for the prompt annotation. > With GDB/MI it seems a little trickier. So far I have this: > Wait for the gdb prompt > If you have not recieved a *running yet, it's safe to run a command. > Otherwise, if you have recieved a *running, you need to wait for > the prompt and for *stopped. > Anyone have a better approach? Does multi target impact this? In most cases, you don't need to care about this. You can normally send other commands even when GDB is blocked and they will be buffered until GDB unblocks. Same goes for the prompt, you don't need to wait for it; you can just send your commands and they will be processed when GDB is ready. Eclipse never waits for the prompt. Are you running mi-async? I recommend doing that. It implies that GDB will always be accepting commands even while the inferior is running. Some commands may fail, such as looking at memory or doing an -exec-next on a thread that is running, and you should be prepared for that, but it is not a big deal. One of the advantages is=20 that you can execute some other commands such as 'info os', listing threads, changing GDB's configuration, etc. With mi-async, there are some cases when you need to wait for the=20 *stopped event. For example, enabling 'record' can only be done when the inferior is stopped, so sending an -exec-interrupt followed by=20 'interpreter-exec console record' is too quick and will fail; instead you must send the -exec-interrupt, wait for *stopped, then enable record. But the majority of cases don't need to wait. =20 > Second, from the CLI if you run the command "next", then if you hit > the enter key, GDB will run the "next" command again. > However, in GDB/MI if you run -interpreter-exec console "next", and then > follow that with the Enter key, GDB does nothing. > Is there a way to run the last command? I don't believe MI supports that. But that feature is really a console fea= ture, I don't see why you'd want that in MI. I assume you don't expect your user to type MI commands manually, so I don't see why they would=20 need to repeat. But if you really want that for some reason, you can just keep track of the last command you sent in MI, and then when getting an lone Enter, you could send it again. But then you don't have the smarts of GDB to know which commands should repeat and which should not. I don't think this is a very good idea. I hope this helps. Marc =20=20=20=20