From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by sourceware.org (Postfix) with ESMTPS id B8CF1385840B for ; Fri, 29 Sep 2023 09:52:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B8CF1385840B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-3231d67aff2so10300381f8f.0 for ; Fri, 29 Sep 2023 02:52:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695981163; x=1696585963; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aljg1zNFmc6LBoCJoS/gD6agsPWrzxNuTqN0tXZLKsY=; b=piRnL5NDwyRTozNl4YPtdYX27L/j03AauvwU6a5vcgASNzxtZw/zkwtHaOoZcvfGEv UogVL6xtiScC8Sapijj4cPD2nwFfQ0bH5ckJ+3UaRlkOgSmpcX0y6C2FCqwMPTU+D/Ce zzXMLPJXlYwCdpwIW2c0i+87J0iWZCT6uDEWhCzG3tBenSGKC8cYJb3Z+nMDBdKuT+2Z tuVy1W4uJr8/ll902lN9CPM/wO/slbj9tZ0iT+LuSHznHnndTXxsnKfEKnWrRNQhSoCo eZWBi7g+asAJ+7GJQaV2zjBMJ5/iex0sTMKpxOHrAuVx1pcs6TzloSVU6rxN1OOxN/fB D0eQ== X-Gm-Message-State: AOJu0YwPrR8qazYdE7IHqk/0JJZSkjpBz2EHLux1YFuNqC/e5cle9UHC nW3wUBut4ZnG3v8bClK+t3I= X-Google-Smtp-Source: AGHT+IGXtGYgi9ZyzS2K11O0r3JdSkc0/4mLRQpZm+YzINPkp+vhHBx4VcQVnpgd0KHHkwKAw1DBHA== X-Received: by 2002:a5d:564c:0:b0:323:37b4:fbe5 with SMTP id j12-20020a5d564c000000b0032337b4fbe5mr3406748wrw.8.1695981163184; Fri, 29 Sep 2023 02:52:43 -0700 (PDT) Received: from ?IPV6:2001:8a0:f939:d200:bc52:8881:959:d6ef? ([2001:8a0:f939:d200:bc52:8881:959:d6ef]) by smtp.gmail.com with ESMTPSA id w10-20020adfd4ca000000b0031762e89f94sm21037313wrk.117.2023.09.29.02.52.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Sep 2023 02:52:42 -0700 (PDT) Message-ID: <636abef0-7d22-e294-7f31-21f98ad3eb2a@palves.net> Date: Fri, 29 Sep 2023 10:52:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Turn history saving on by default? (Re: GDB BoF notes - GNU Cauldron 2023) Content-Language: en-US To: Lancelot SIX , Guinevere Larsen Cc: gdb@sourceware.org References: <1e26c71e-e242-de11-a687-46e05586e608@palves.net> <19c57e96-288e-1954-c211-93fc4b22b43e@redhat.com> <20230929092410.u4j5i73bpg5ictyw@octopus> From: Pedro Alves In-Reply-To: <20230929092410.u4j5i73bpg5ictyw@octopus> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: On 2023-09-29 10:24, Lancelot SIX wrote: >>> - 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. Of what happens if you start GDB without a binary at all? > > 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. > My thoughts exactly. +1. On my bash for example, I got recently annoyed with all my ssh shells overwriting the same history file, so I came up with a way to have easy separate bash history sessions. But, I still think that the bash default is OK. The only viable options that I can think of for gdb are: #1 - don't save history (current default) #2 - save history in current dir #3 - save history in $HOME (or somewhere XDG if it makes system for the system) #1 is of course the current default. #2 is what I do in my .gdbinit: set history save on set history filename .gdb_history set history size unlimited This works well enough for me. It does have the downside of sprinkling .gdb_history files all over the place, which gets a bit annoying at times. E.g., sometimes I'll spawn gdb in a random directory because I often use gdb as my calculator :-) ("(gdb) p 1 + 2 * 3", etc.), which ends up with a .gdb_history file in that dir. Still, it's my choice, and I am aware of the consequences. #3 seems like a reasonable default to me, which doesn't have that "sprinkle files throughout the filesystem" issue.