From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23666 invoked by alias); 16 Sep 2016 18:26:00 -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 23646 invoked by uid 89); 16 Sep 2016 18:25:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=ah X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Sep 2016 18:25:58 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7383913A60; Fri, 16 Sep 2016 18:25:57 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8GIPuGQ026252; Fri, 16 Sep 2016 14:25:56 -0400 Subject: Re: [PATCH master+7.12 v2 2/3] Emit inferior, thread and frame selection events to all UIs To: Simon Marchi References: <20160914174548.5873-1-simon.marchi@ericsson.com> <20160914174548.5873-3-simon.marchi@ericsson.com> <8f1b10b3-131d-df38-573f-dedf0cc0103d@redhat.com> <07211f1c-5e9e-3bfc-9fbe-481ae350b6ac@ericsson.com> Cc: gdb-patches@sourceware.org, Antoine Tremblay From: Pedro Alves Message-ID: <11df053c-4103-8af9-6875-5d8eb594a819@redhat.com> Date: Fri, 16 Sep 2016 18:26:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <07211f1c-5e9e-3bfc-9fbe-481ae350b6ac@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-09/txt/msg00189.txt.bz2 On 09/15/2016 05:20 PM, Simon Marchi wrote: > On 16-09-14 02:30 PM, Pedro Alves wrote: >> We could solve that by adding the thread group id (inferior id) to >> the notification, I think: >> >> =thread-selected,id="3",thread-group="i1",frame="..." >> >> =thread-selected,id="0",thread-group="i2",frame="..." >> >> ... >> > That sounds good. I think we can plan this for 7.13 though, the goal now is > to get the basic use cases working, while not breaking any previous ones. OK. >> But, I suspect that we end up suppressing this case: >> >> (gdb) define thread-foo >>> thread $arg0 >>> end >> (gdb) thread-foo 2 >> >> Contrived, but certainly not hard to imagine user-commands doing >> something useful along with changing the selected thread. >> >> What happens in this case? > > I think that's actually the opposite. The purpose of this whole ugly condition > is to avoid sending a second event, if we removed that whole part with strcmp's, > we would end up sending events twice. It would not be nice, but it would not be > as bad as not sending any event. Ah! > That big condition is clearly unclear though :). I suggest breaking it in its own > function, where it will be more readable (even though not technically better): Indeed, that'd be a great boon. > > And then the condition becomes readable, and we understand the intent: > > > /* If the command already reports the thread change, no need to do it > again. */ > && !command_sends_thread_selected_event (command)) > ... Awesome! > > > To address you uneasiness with -thread-select, let's see how that that code interacts > with that command. First, an event about the thread change is sent in > mi_cmd_thread_select. Then, command_sends_thread_selected_event will return true, > making us skip sending the event again. > > WDYT? I like it. Thanks, Pedro Alves