From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30837 invoked by alias); 9 Jun 2019 10:31:50 -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 30829 invoked by uid 89); 9 Jun 2019 10:31:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?Yes, score=8.0 required=5.0 tests=BAYES_99,CHINA_SUBJECT,DEAR_SOMETHING,FREEMAIL_FROM,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,INVALID_MSGID autolearn=no version=3.3.1 spammy=sea, freight, Logistics, 8:=e6?= 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; Sun, 09 Jun 2019 10:31:49 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hZv75-00056Z-4l for gdb@sourceware.org; Sun, 09 Jun 2019 06:31:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34854) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hZv74-00077z-Qo for bug-gdb@gnu.org; Sun, 09 Jun 2019 06:31:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hZv73-00055g-Ht for bug-gdb@gnu.org; Sun, 09 Jun 2019 06:31:46 -0400 Received: from [27.38.243.74] (port=38146 helo=habig.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hZv72-00053U-3M for bug-gdb@gnu.org; Sun, 09 Jun 2019 06:31:45 -0400 Received: from desktop ([127.0.0.1]) by localhost via TCP with ESMTPA; Sun, 09 Jun 2019 18:24:42 +0800 Message-ID: d1702caa-eceb-4532-af76-07997aae1b79 MIME-Version: 1.0 From: "simon" <1981484021@qq.com> To: bug-gdb@gnu.org Date: Sun, 09 Jun 2019 10:31:00 -0000 Subject: Shipment from China X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 27.38.243.74 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-06/txt/msg00011.txt.bz2 RGVhciBTaXI6DQombmJzcDsNCkdvb2QgZGF5DQombmJzcDsNClNpbW9uIGdy ZWV0aW5nIGZyb20gRXZlcmJyaWdodCBpbnRlcm5hdGlvbmFsIGxvZ2lzdGlj cyBjby4sbHRkLGFuZCB3ZSBzcGVjaWFsaXplIGluIG92ZXJzZWFzIGludGVy bmF0aW9uYWwgbG9naXN0aWNzIGZvciAxNSB5ZWFycyxvdXIgbWFqb3IgY29y ZSBidXNpbmVzcyBzY29wZSBjb3ZlcjoNCiZuYnNwOw0KSW50ZXJuYXRpb25h bCBzZWEgZnJlaWdodA0KSW50ZXJuYXRpb25hbCBhaXIgZnJlaWdodA0KSW50 ZXJuYXRpb25hbCBjb3VyaWVyIHNlcnZpY2UNCkxvY2FsIGxvZ2lzdGljcyBz ZXJ2aWNlIHN1Y2ggYXMgdHJ1Y2tpbmcsY3VzdG9tcyBjbGVhcmFuY2UgLHdh cmVob3VzaW5nLGNvbnNvbGlkYXRpb24gc2VydmljZSANCiZuYnNwOw0KV2Ug Y2FuIGdpdmUgeW91IHF1b3RhdGlvbiBkaXJlY3RseSBmb3IgeW91ciBzaGlw bWVudCB1bmRlciBleC13b3JrLGZvYixkZHUsYW5kIGRkcCB0ZXJtcyxhbmQg dGhpcyBjYW4gcmVkdWNlIGEgbG90IG9mIGxvZ2lzdGljcyBjb3N0IGJldHdl ZW4geW91ciBhbmQgeW91ciBzaGlwcGVyIGluIGNoaW5hICxhbmQgYWxzbyB1 cGRhdGVkIHlvdSB0aGUgc2l0dWF0aW9uIG9mIHlvdXIgc2hpcG1lbnQgcXVp Y2tseSANCiZuYnNwOw0KU2hvdWxkIHlvdSBoYXZlIGFueSBpbnRlcmVzdCxh bGwgdGhlIGNlcnRpZmljYXRlcyBhbmQgcHJvZmlsZSBvZiBvdXIgY29tcGFu eSB3aWxsIGJlIHNlbnQgdG8geW91IGZvciBjaGVja2luZyxhbmQgYWxzbyB5 b3UgY2FuIGFkdmlzZSB5b3VyIGlucXVpcnksbGF0ZXN0IHJhdGUgd2lsbCBi ZSB1cGRhdGVkIHRvIHlvdSB3ZWVrbHkNCiZuYnNwOw0KV2UgbWF5IGhhdmUg bm8gdGltZSxidXQgd2Ugd2lsbCBtYWtlIGl0Jm5ic3A7DQpXZSBtYXkgaGF2 ZSBubyBhbnN3ZXIsYnV0IHdlIHdpbGwgZmluZCBpdCZuYnNwOw0Kd2UgbWF5 IGJlIG5vdCB0aGUgYmVzdCxidXQgd2UgYXJlIHRoZSBtb3N0IGNvbW1pdGVk IHRvIHlvdXIgc3VjY2Vzcw0KV2UgY2Fycnksd2UgY2FyZSZuYnNwOw0KJm5i c3A7DQoNCiZuYnNwOyZuYnNwOw0KDQoNClNpbW9uIEdlbmVyYWwgTWFuYWdl cg0KU2hlbnpoZW4mbmJzcDtFdmVyQnJpZ2h0Jm5ic3A7SW50ZXJuYXRpb25h bCZuYnNwO0xvZ2lzdGljcyZuYnNwO2NvLixsdGQuDQpSb29tJm5ic3A7N0Qs Jm5ic3A7QmxvY2smbmJzcDsxLCZuYnNwO0NoZW5neGluJm5ic3A7SHVhdGlu ZyZuYnNwO01hbnNpb24sDQombmJzcDtOby4xJm5ic3A7b2YmbmJzcDtTcXVh cmUmbmJzcDtSb2FkLCZuYnNwOyZuYnNwO0J1amksJm5ic3A7TG9uZ2dhbmcm bmJzcDtkaXN0cmljdCwmbmJzcDtTaGVuemhlbiwmbmJzcDtDaGluYVRlbC8m bmJzcDtGYXg6Jm5ic3A7MDA4Ni03NTUtMjg3NTg1NjUmbmJzcDsNCk1vYmls ZTowMDg2LTE4NjY1OTQ2MjU1DQpFbWFpbDpzYWxlczAzQHN6ZXZlcmJyaWdo dC5jb20NCg0KJm5ic3A7DQoNCiZuYnNwOw0KYnVnLWdkYkBnbnUub3JnMjAx OeW5tDA25pyIMDnml6UxOOaXtjI05YiGNDLnp5JHUVJOYWRjYkxWTUJTUEht UEFsTlZ1WEZvSGh0S2NZTG9mZndMSXJLeFNua3B4dFk= >From gdb-return-47046-listarch-gdb=sources.redhat.com@sourceware.org Mon Jun 10 21:19:34 2019 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 125307 invoked by alias); 10 Jun 2019 21:19:33 -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 125294 invoked by uid 89); 10 Jun 2019 21:19:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=complicated, notifications, aspect X-HELO: relay.fit.cvut.cz Received: from relay.fit.cvut.cz (HELO relay.fit.cvut.cz) (147.32.232.237) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Jun 2019 21:19:31 +0000 Received: from imap.fit.cvut.cz (imap.fit.cvut.cz [IPv6:2001:718:2:2901:0:0:0:238]) by relay.fit.cvut.cz (8.15.2/8.15.2) with ESMTPS id x5ALJQar025328 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 10 Jun 2019 23:19:28 +0200 (CEST) (envelope-from jan.vrany@fit.cvut.cz) Received: from [IPv6:2a02:c7d:2fcb:c700:6267:20ff:fee4:3e2c] ([IPv6:2a02:c7d:2fcb:c700:6267:20ff:fee4:3e2c]) (authenticated bits=0 as user vranyj1) by imap.fit.cvut.cz (8.15.2/8.15.2) with ESMTPSA id x5ALJN69071739 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 10 Jun 2019 23:19:26 +0200 (CEST) (envelope-from jan.vrany@fit.cvut.cz) Message-ID: <70fdd9107d9bb3cee0a1a342aedc05bf3c8e9bae.camel@fit.cvut.cz> Subject: MI3 and async notifications From: Jan Vrany To: "gdb@sourceware.org" Date: Mon, 10 Jun 2019 21:19:00 -0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00012.txt.bz2 Content-length: 1498 Hello, as an user og GDB/MI (and frontent developer), I'd like to open a discussion about one aspect of MI that I'd like to change in MI3 before it is released into the wild. Currently, quite a few commands suppress async notifications when a command is issued through MI. For example, when a breakpoint is added using -break-insert then =breakpoint-created is not emitted. At least in my case, this behavior complicates client design because now the client has to care for new breakpoints on multiple places: (i) listen to breakpoint created events to handle cases where breakpoint is added via CLI. (ii) do similar processing whenever MI returns ^done for previously issued -break-insert command. This leads to a complex logic, especially in cases where frontend has some scripting support (so execution of MI commands is not completely under frontend developer's control). Emitting notifications unconditionally would simplify things a lot - again at least in my case. Therefore I'd like to propose a change for MI3 to always send notifications. If such a change would make things complicated for other frontends (Eclipse CDT / Emacs come to mind), I propose new -gdb-set mi-always-notify 1 -gdb-set mi-always-notify 0 setting to control the behavior so frontends may choose. I'm happy to submit a patch. Are there any other frontend developers? If so, would it be OK to always notify in MI3 or do you prefer to have an option? Any other comments? Thanks! Jan