From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +EmhJt2XFmV3+h8AWB0awg (envelope-from ) for ; Fri, 29 Sep 2023 05:24:45 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=nVO9dQZL; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 949461E0C3; Fri, 29 Sep 2023 05:24:45 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 845701E028 for ; Fri, 29 Sep 2023 05:24:43 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AAD2C3858C01 for ; Fri, 29 Sep 2023 09:24:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AAD2C3858C01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1695979482; bh=vrrPr7OTJw3QcCDuWpJ5oEvBlSyvfK4icBTEY1Kqxac=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=nVO9dQZLq1i4PDTEJ71sVtI9JbXfBJdtm2ns7jj0E3FuQR5A3q+An6I7Hi4jbXPnc aO6zmn+uS/VQqU/+ybv7Ol3m4TVc44M3/7noCTfF9q16ih4wtJY+wLMj+dVA74uwTQ udjqnLsJO7fKkmAagwEwjfphYWT/VrdRsVNfOVWQ= Received: from lndn.lancelotsix.com (lndn.lancelotsix.com [51.195.220.111]) by sourceware.org (Postfix) with ESMTPS id 5B44B3858C01 for ; Fri, 29 Sep 2023 09:24:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5B44B3858C01 Received: from octopus (cust120-dsl54.idnet.net [212.69.54.120]) by lndn.lancelotsix.com (Postfix) with ESMTPSA id DC3018A5FD; Fri, 29 Sep 2023 09:24:14 +0000 (UTC) Date: Fri, 29 Sep 2023 10:24:10 +0100 To: Guinevere Larsen Cc: Pedro Alves , gdb@sourceware.org Subject: Re: GDB BoF notes - GNU Cauldron 2023 Message-ID: <20230929092410.u4j5i73bpg5ictyw@octopus> References: <1e26c71e-e242-de11-a687-46e05586e608@palves.net> <19c57e96-288e-1954-c211-93fc4b22b43e@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19c57e96-288e-1954-c211-93fc4b22b43e@redhat.com> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (lndn.lancelotsix.com [0.0.0.0]); Fri, 29 Sep 2023 09:24:15 +0000 (UTC) X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Lancelot SIX via Gdb Reply-To: Lancelot SIX Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" > > - Revisiting defaults > > > > - Can we turn history saving on by default? Maybe default to > > history on home dir by default, too (~/.gdb_history). That would > > align us with bash. Some in the room have had this enabled in > > their gdbinits for so long they no longer remembered this wasn't > > on by default. Others weren't even aware you can turn this on. > > One issue I find with the bash approach is that you end up mixing history > between multiple unrelated sessions. Bash can't solve this but GDB possibly > could. > > My suggestion would be to use an approach similar to vim's swap files. As an > example, editing the maintainers file, I have the file ~/.local/state/nvim/swap/%home%blarsen%Documents%binutils-gdb%gdb%MAINTAINERS.swp; > This way you can have histories specific to any binary you're debugging > without mixing sessions. > Hi, With such approach, I am not really sure how to name/identify a session. Is that based on the name of the binary you're debugging? If so what happens if you use `file another_bin`? Either you switch to another "session", but really you never left GDB so that would seem odd to me, or you end up having history about another_bin in your first apparently unrelated session. Similarly, when dealing with multiple inferiors, would running `inferior N` switch from session to session? I can see cases where such behavior could be helpful, but there seems to be a lot of edge cases where it could become strange. My feeling for now is that the best way to achieve this is to save the gdb history in the current directory, with the "risk" of having plenty of history files left all-over the place (as you mentioned already). I feel that having the default somewhere under $HOME / $XDG_STATE_HOME (as suggested by Tom) seems an "easier" default. Best, Lancelot. > That said, either option is an improvement to the current state, so I'm all > for it! > > Another solution that was brought up, seeing as the biggest concern was > having many "gdb_history"s lost across the filesystem, was to make the > history not hidden. I'm not a big fan of this approach, but figured it was > worth bringing up. > > > > > - Can we disable pagination by default? Surprisingly, no one in the > > room expressed that they like pagination on. Sevearl people > > mentioned that they have it off by default, and then use either > > the terminal scroll function, or: > > > > "(gdb) pipe GDB_COMMAND | less" > > > > when necessary. > > > The one use-case mentioned for pagination was that you can't scroll on the > tui. It is possible to have "pagination auto" behave differently. As someone > who doesn't use the TUI, I don't have a stake on this decision, again just > figured I should share. > > -- > Cheers, > Guinevere Larsen > She/Her/Hers >