From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) by sourceware.org (Postfix) with ESMTPS id 1E916385F011 for ; Wed, 15 Apr 2020 02:13:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1E916385F011 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=brasko.net Authentication-Results: sourceware.org; spf=none smtp.mailfrom=bob@brasko.net Received: by mail-qt1-x843.google.com with SMTP id b10so12045029qtt.9 for ; Tue, 14 Apr 2020 19:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasko-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=t81U3ENNPxl4uHoy4SevvVI/LbDZF83Py7usnUxD4B0=; b=H6bUTvwMoF50PuYU+xIBsuoBqPCCQUPWnXKdxmUOzbupEgl7abwlHZuKvk4N+ogiV/ vdGOPaKgfjqQ8Xdaeqndk8OzArM9k/Y5gutgIdUtpUJ12mxCAO3gNES8Ond8rMrYn/f/ E6slUWFjJ0KmN0oy1yO9Xc6SD0uX1uutsC1NTkJ0+Gp7ufvYBYUcPOlwbRUfahH5YESg bAo7qL6x0y7CKgQP2CfpUy6CyiH8SPwQUAim28Lk2Gy8MMNVfC71zEK20m1XwY/TlKkZ 4EG9C3n+yYa61yTUP4E5qF01huoP4EmYy0rAF6ov8g1bEP4fCqYhcYsk62Surc2me1Ez aNKg== 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:user-agent; bh=t81U3ENNPxl4uHoy4SevvVI/LbDZF83Py7usnUxD4B0=; b=Xiip5AIK3q/mTCOQS/SmZy4maZ+T/vsve1BY58wxomrYu8B4cC7Nhi1es2fHiZEO9c dWLeB+bqqg1DfAkxMAUCJkzRyhLn7mLo30TB/hvwwBzd5d6uBxu7I/T2BdFGtz30QycT xWZtgfJXn4HnbGavsm+11qg8vhQs3gToF/p/dql1Dx1jvfDN+YJ8wBSNQFIOKxOEuLfH qK9zH7HX8fjMKlYJd77EMwiPSo9mqGVVhItcDlpOBbDm/PJhgbHRquSbYkncmYpP6QDX nVvW+IarJt4urlctKXhk9HxpF4sHY1Qw38l+LSpxtoTTfrh9fFQ3OXvyGXCzDME8Ylo3 9RWA== X-Gm-Message-State: AGi0PubUDz1wtiNM1CG8UGLi5tmv9QFSVP9nO3d24gOZ9eptMtTabu/e JN7S97E3JgUUbsy9XCofLt6FEwCT1vc= X-Google-Smtp-Source: APiQypJo7h6pzsIX/IoMNKz92uRSd12tkky09/cGoTqwotv5RS3R8nRX83VcXtWT+MdZ+57Lnrm6ww== X-Received: by 2002:ac8:65d6:: with SMTP id t22mr616750qto.241.1586916806641; Tue, 14 Apr 2020 19:13:26 -0700 (PDT) Received: from xubuntu.brasko.net (pool-108-34-130-131.prvdri.fios.verizon.net. [108.34.130.131]) by smtp.gmail.com with ESMTPSA id n10sm11013735qkk.105.2020.04.14.19.13.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2020 19:13:26 -0700 (PDT) Date: Tue, 14 Apr 2020 22:13:24 -0400 From: Bob Rossi To: Andrew Burgess Cc: gdb@sourceware.org Subject: Re: source annotation now prints source line Message-ID: <20200415021324.GB31494@xubuntu.brasko.net> References: <20200404235424.GB5321@xubuntu.brasko.net> <20200414112304.GB22764@xubuntu.brasko.net> <20200414121705.GD2366@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200414121705.GD2366@embecosm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, 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: Wed, 15 Apr 2020 02:13:28 -0000 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. Thanks, Bob Rossi