From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35827 invoked by alias); 22 Nov 2018 14:20:58 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 35795 invoked by uid 89); 22 Nov 2018 14:20:58 -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.2 spammy=H*r:may, H*r:forged, target_ops, am 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; Thu, 22 Nov 2018 14:20:53 +0000 Received: from imap.fit.cvut.cz (imap.fit.cvut.cz [147.32.232.238]) by relay.fit.cvut.cz (8.15.2/8.15.2) with ESMTPS id wAMEKl2W061729 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Nov 2018 15:20:49 +0100 (CET) (envelope-from jan.vrany@fit.cvut.cz) Received: from debian-sid-rv64 (02790367.bb.sky.com [2.121.3.103] (may be forged)) (authenticated bits=0 as user vranyj1) by imap.fit.cvut.cz (8.15.2/8.15.2) with ESMTPSA id wAMEKkiS006412 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 22 Nov 2018 15:20:47 +0100 (CET) (envelope-from jan.vrany@fit.cvut.cz) Message-ID: Subject: Re: [RFC 2/2] gdb/mi: add new async events =target-connected and =target-disconnected From: Jan Vrany To: Simon Marchi , "gdb-patches@sourceware.org" Date: Thu, 22 Nov 2018 14:20:00 -0000 In-Reply-To: <771a41a2-15e9-e8a6-ef66-767d4277a08d@ericsson.com> References: <20181014125534.11724-1-jan.vrany@fit.cvut.cz> <20181014125534.11724-3-jan.vrany@fit.cvut.cz> <771a41a2-15e9-e8a6-ef66-767d4277a08d@ericsson.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.2-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-11/txt/msg00367.txt.bz2 Hi, sorry for late answer, I was traveling last couple weeks. On Thu, 2018-10-18 at 01:31 +0000, Simon Marchi wrote: > On 2018-10-14 8:55 a.m., Jan Vrany wrote: > > Whenever a target is connected or disconnected, emit new asynchronous > > event =target-connected and =target-disconnected. Events report > > both short name and full name of connected or disconnected target. > > In addition, =target-connected report a set of target features. > > > > This allows frontends to keep track of current target and its features > > regardless whether target is changed explicitly by MI -target-select > > command, CLI target command or implicitly by native target auto-connect. > > Thanks, I like the idea. A non-RFC version of this would require corresponding > tests to be accepted. I'll add some. > > > @@ -1271,6 +1275,73 @@ mi_user_selected_context_changed (user_selected_what selection) > > } > > } > > > > +static void > > +mi_target_connected (struct target_ops *target) > > +{ > > + SWITCH_THRU_ALL_UIS () > > + { > > + struct mi_interp *mi = as_mi_interp (top_level_interpreter ()); > > + struct ui_out *mi_uiout; > > + > > + if (mi == NULL) > > + continue; > > + > > + mi_uiout = top_level_interpreter ()->interp_ui_out (); > > + > > + target_terminal::scoped_restore_terminal_state term_state; > > + target_terminal::ours_for_output (); > > + > > + fprintf_unfiltered (mi->event_channel,"target-connected"); > > + > > + mi_uiout->redirect (mi->event_channel); > > + > > + mi_uiout->field_string ("type", target->shortname()); > > + mi_uiout->field_string ("name", target->longname()); > > + > > + { > > + ui_out_emit_list list_emitter (mi_uiout, "features"); > > + > > + if (mi_async_p ()) > > + mi_uiout->field_string (NULL, "async"); > > + if (target_can_execute_reverse) > > + mi_uiout->field_string (NULL, "reverse"); > > + } > > + > > + mi_uiout->redirect (NULL); > > + > > + gdb_flush (mi->event_channel); > > + } > > +} > > I think there is a (kind of corner-case, but still) bug with using > mi_async_p and target_can_execute_reverse. Here are some CLI commands > I type in a "gdb -i mi", and the corresponding > =target-connected/disconnected event: > > set mi-async on > file test > =target-connected,type="exec",name="Local exec file",features=[] > > start > =target-connected,type="native",name="Native process",features=["async"] > > record > =target-connected,type="record-full",name="Process record and replay target",features=["async","reverse"] > > file > =target-disonnected,type="exec",name="Local exec file" > > file /bin/ls > =target-connected,type="exec",name="Local exec file",features=["async","reverse"] > > That last event says the exec target supports async and reverse, which is wrong. > So you would need to write an equivalent of mi_async_p/target_can_execute_reverse > to which you can pass a target_ops*, it should not be too hard. Yes, you're right, will fix that. But this example shows a deeper problem - it is hard to interpret these events. Perhaps I'm wrong but: from the user point of view, GDB can be connected to only one target, no? But if you look at events, it looks like targets "native" and "record-full" are still connected. They are, really, the inferiror is still running, can be single-stepped and so on. So actually I'd expect something like: file test =target-connected,type="exec",name="Local exec file",features=[] start =target-disonnected,type="exec",name="Local exec file"Simon=target-connected,type="native",name="Native process",features=["async"] record =target-disconnected,type="native",name="Native process" =target-connected,type="record-full",name="Process record and replay target",features=["async","reverse"] file # Nothing, we're still connected and still recording file /bin/ls # Nothing, we're still connected and still recording record stop =target-disconnected,type="record-full",name="Process record and replay target" =target-connected,type="native",name="Native process",features=["async"] kill =target-disconnected,type="native",name="Native process" =target-connected,type="exec",name="Local exec file",features=[] Makes sense? We may say that =target-connected means that previously connected target has disconnected. I'd prefer not to, since you mentionedsome time ago that Pedro is working on multiple target support (in that case all we need is to add a kind of "id" field to target notification events) In any case I find =target-connected after issuing "file" command rather confusing. Makes sense? Jan