From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=lancelotsix.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=lancelotsix.com 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lancelotsix.com; s=2021; t=1695979455; bh=JYXsj6ggWcDS+WHlFr9Fltfpu9p37DjaMFl3r1RIl/4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NQdctRQNncRe4CqO4Llj46tAyq02UO2B8zEZPeYic5Nyc9EnlP0Wz1QX6JwsDnQ8C ypyU9OU+n9lvrif/GjLkNt9DBjoTmL7kwXZvoaIbp66/nqxluxHXw2mODmKkp2sdQa X/TsWZuL01IKcutjworD9XkEQ3QvblScBg0Y6lBvczmBikXm8vnszdZtqiMjfXXI8I FHLubSE9Qo3dnRHKHECghYvwPInXlyBarUEKyOwC4HIajtNoAmaMjF6H7H5BRmrppi ELLUp/Zp1lBSD85QG++iqo1KPl8Rc84sSmXsmOPdQSU0QzQK4vmjGy/uArGih2oneg soeiNULHblphA== Date: Fri, 29 Sep 2023 10:24:10 +0100 From: Lancelot SIX 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 List-Id: > > - 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 >