From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by sourceware.org (Postfix) with ESMTPS id 4A4BC385B835 for ; Thu, 16 Apr 2020 17:41:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4A4BC385B835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wr1-x442.google.com with SMTP id b11so5845547wrs.6 for ; Thu, 16 Apr 2020 10:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uGk4sxUs+Lh+6AWH9RFvYWRzQc/DfI6ZSx0+sVey7CU=; b=aiGHyA+ZsXropkQznGX1lB9bYqo29wjhqD/kVDxsRnoW1pjDLUvJAPSsJHYvqud3o7 y+E8UtrFq9+AqurXDzJr68ma4nlHv/Rznq0pnvbTY1sYC4Lew+g+OkxTddBUc+L7jQJW EAoL294Bh6heF/wl0bv/ZcfoFaBRifamfRLSy6A234/c7HmKDzs5phzDIsgmbuZSK033 p1TmurUR00VT+fzGdRsS+Z7OqlBF6g7ee9mhaXsmyTPnWGhNIaffp/Q0xG4Dp4F42xiQ KO5Dth7yKn8iwweuV7HAq6XYF1yd/OUro7hU26+lhNmkDi2Jq7PwayZ5Ae9bpO/+hC3F uh/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uGk4sxUs+Lh+6AWH9RFvYWRzQc/DfI6ZSx0+sVey7CU=; b=ZUqmNldRsmx3GMCeD5VSWsb+Hi7rmNR2GLmrazVo5s6UGBsVtFdzNjG7WaZekE+2gl nbs4fa4iSa2hN6fqJpEiRfPD+joRbvrPnmRWRnFi1OY6VgWPICuX4eIZ8nBiqGUz/IFb guRLRl710iLawXIJN2PauBmnB0BubK+xmMMm4/k8Msd4y7vSmUsRYg+huFWHyGuFlLoX GlWRXQ39fyhvpBGFq7E2mvlRYEU9qZGIkhwYUc1ejeSFajNSFpzxqvdOIi+J0K+vZH0d dRSkWo+DX+p4jqtf6otxmulwu0BZM/h3mD9R8GNXQ92pieq2tYlfk2RAM2vcUBDalCkX d87Q== X-Gm-Message-State: AGi0PuZ2dsn9q38lJamxUlXc2krAG2dGGakX7R12pd30Uo7qdkIU/Fcq +z1OuD728UVZoXckmLsHnH6gnjrQHGM= X-Google-Smtp-Source: APiQypLnbXMOGfd2nP8Emwp/QND+HfKBw5+iu3OGYpAmZq6EJojIKp4cMU8A/4aQ8Q2IJ+jg2GHtpQ== X-Received: by 2002:a5d:4ed1:: with SMTP id s17mr30630629wrv.310.1587058891177; Thu, 16 Apr 2020 10:41:31 -0700 (PDT) Received: from localhost (host81-151-181-184.range81-151.btcentralplus.com. [81.151.181.184]) by smtp.gmail.com with ESMTPSA id 36sm12720847wrc.35.2020.04.16.10.41.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Apr 2020 10:41:30 -0700 (PDT) Date: Thu, 16 Apr 2020 18:41:28 +0100 From: Andrew Burgess To: Bob Rossi Cc: gdb@sourceware.org Subject: Re: source annotation now prints source line Message-ID: <20200416174128.GA1633140@embecosm.com> References: <20200404235424.GB5321@xubuntu.brasko.net> <20200414112304.GB22764@xubuntu.brasko.net> <20200414121705.GD2366@embecosm.com> <20200415021324.GB31494@xubuntu.brasko.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200415021324.GB31494@xubuntu.brasko.net> X-Operating-System: Linux/5.5.13-200.fc31.x86_64 (x86_64) X-Uptime: 18:32:50 up 8 days, 8:47, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-11.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 17:41:34 -0000 * Bob Rossi [2020-04-14 22:13:24 -0400]: > On Tue, Apr 14, 2020 at 01:17:05PM +0100, Andrew Burgess wrote: > > * Bob Rossi [2020-04-14 07:23:04 -0400]: > > > > > On Sat, Apr 04, 2020 at 07:54:24PM -0400, Bob Rossi wrote: > > > > When the source annotation is sent to the front end, the source line > > > > is now also sent to the front end console. I believe this commit > > > > introduced it, > > > > https://github.com/bminor/binutils-gdb/commit/ec8e2b6d3051f0b4b2a8eee9917898e95046c62f > > > > > > > > Now CGDB displays, > > > > (gdb) n > > > > 43 int i = 3; > > > > (gdb) > > > > > > > > Instead of, > > > > (gdb) n > > > > (gdb) > > > > > > > > CGDB is a front end, and so it has a source view to display the code to > > > > the user. Why did GDB decide to also print the line of code to the front > > > > end's console window as well? This is confusing. > > > > > > The concept behind this commit seems incorrect. > > > > > > The motivation for the patch isn't clearly explained in > > > the commit message. I believe I've given a reasonable explanation > > > on why this patch makes no sense for front ends. > > > > > > Should I submit a patch reverting it? > > > > The patch in context is discussed here: > > > > https://sourceware.org/pipermail/gdb-patches/2019-June/158310.html > > https://sourceware.org/pipermail/gdb-patches/2019-June/158350.html > > https://sourceware.org/pipermail/gdb-patches/2019-June/158351.html > > https://sourceware.org/pipermail/gdb-patches/2019-June/158352.html > > https://sourceware.org/pipermail/gdb-patches/2019-June/158353.html > > > > I'm not sure you've convinced me yet that the idea behind the patch is > > incorrect. Annotations should be a (deprecated) way for F/Es to parse > > GDB's output, but they shouldn't impact _what_ GDB prints. > > Annotation are still useful for the single purpose of allowing GDB > to tell you when the user is at the prompt. This allows front ends > to know when to issue a new command. > > > In this particular case, printing the source line actually updates > > some internal state, which impacts how later commands operate. What > > this means is that the users session will behave differently if they > > have annotations on than when annotations are off. > > I see. Seems good to have fixed that. Although I wonder how relevant > that information was as front ends have been using annotations for > 20+ years without having noticed. Was this found from a user bug report? > > > I guess, what I don't understand is that if a F/E wants to hide a > > particular piece of the output, why can't it just strip that from the > > output stream? The F/E must already be removing the annotation > > markers, so all the output must be going through the F/E anyway. > > Front ends can not parse gdb's output. It's the golden rule. > It's unreliable and will ultimately fail. > > > Further, removing this particular piece of output makes sense for this > > F/E, but is it always going to be true for all F/Es? > > Yes, it does. It worked this way for 20+ years, and everyone was happy. > Was this added in because an actual user complained? > > Even the tui does not show the source output in the console, even > after your patch. To our great shame, the relevant code here is (from stack.c): if (deprecated_print_frame_info_listing_hook) deprecated_print_frame_info_listing_hook (sal.symtab, sal.line, sal.line + 1, 0); else { // .... print the source lines .... } And in tui/tui-hooks.c we have: deprecated_print_frame_info_listing_hook = tui_dummy_print_frame_info_listing_hook; and: static void tui_dummy_print_frame_info_listing_hook (struct symtab *s, int line, int stopline, int noerror) { } Why am I telling you this? It basically is a convoluted way of saying: if (!tui) { // ...... print the source lines .... } This certainly backs up your point that GUI users don't want to see the information in both the GDB terminal _and_ in their GUI. Which interestingly, would suggest that the TUI is going to have the same set of bugs that the annotations would trigger. But in terms of implementation the TUI is special casing itself. I'll take a look to see if there's a good way to give you the functionality you're looking for and close the bugs off. Thanks, Andrew > > Thanks, > Bob Rossi