From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61416 invoked by alias); 13 Mar 2019 15:50:38 -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 61399 invoked by uid 89); 13 Mar 2019 15:50:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=HX-Received:6112, displays, pressed, H*M:1826 X-HELO: mail-wr1-f43.google.com Received: from mail-wr1-f43.google.com (HELO mail-wr1-f43.google.com) (209.85.221.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Mar 2019 15:50:36 +0000 Received: by mail-wr1-f43.google.com with SMTP id g18so2573928wru.3 for ; Wed, 13 Mar 2019 08:50:36 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id g10sm16420055wrq.61.2019.03.13.08.50.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Mar 2019 08:50:34 -0700 (PDT) Subject: Re: [RFC] Don't show "display"s twice in MI To: Tom Tromey References: <20190312190320.19645-1-tromey@adacore.com> <0a23b883-9c80-a9e2-1e3e-3aa8c0b0ce13@redhat.com> <87y35ix0pv.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <3cf86a8c-3448-1826-61bc-dff0faaa0744@redhat.com> Date: Wed, 13 Mar 2019 15:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87y35ix0pv.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-03/txt/msg00273.txt.bz2 On 03/13/2019 03:17 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > >>> Probably we shouldn't print the displays in that case, just to keep >>> things simple, respecting should_print_stop_to_console, but not 100% >>> sure. > > Pedro> So your patch makes GDB not do the displays in the > Pedro> -exec-step/-exec-next case, which is the solution I was > Pedro> leaning to above too, even though I'm not 100% sure about it. > > I'm not 100% sure either. > > We could have a more complicated patch that arranges for do_displays to > be called just once, no matter what decision is made. Maybe this would > be better? Maybe we could simply move the do_display call elsewhere? > I originally thought it was somewhat odd to deal with displays in an MI > stepping situation -- MI clients presumably would use varobj. Yeah, that's not the way to look at it, IMO. > But, really the scenario is that the MI client provides a console, the user > types "display ...", and then debugs some more. I suppose the way that > the "next" is done wouldn't matter to the user? Yeah. Thinking a bit more, I think I'd be surprised if my console-created "display" wasn't redisplayed in the console regardless of whether I pressed a "next" button, or typed "next" in the console. Kind of the mirror view of creating a "watch expression" thingy in Eclipse (or whatever), which is implemented with varobjs, and then that widget not updating with "next" in the console. Thanks, Pedro Alves