public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Lancelot SIX <lsix@lancelotsix.com>
To: Guinevere Larsen <blarsen@redhat.com>
Cc: Pedro Alves <pedro@palves.net>, gdb@sourceware.org
Subject: Re: GDB BoF notes - GNU Cauldron 2023
Date: Fri, 29 Sep 2023 10:24:10 +0100	[thread overview]
Message-ID: <20230929092410.u4j5i73bpg5ictyw@octopus> (raw)
In-Reply-To: <19c57e96-288e-1954-c211-93fc4b22b43e@redhat.com>

> > - 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
> 

  reply	other threads:[~2023-09-29  9:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-27 12:41 Pedro Alves
2023-09-27 13:55 ` Simon Marchi
2023-09-27 14:00 ` Guinevere Larsen
2023-09-29  9:24   ` Lancelot SIX [this message]
2023-09-29  9:52     ` Turn history saving on by default? (Re: GDB BoF notes - GNU Cauldron 2023) Pedro Alves
2023-09-29 10:30       ` Guinevere Larsen
2023-09-27 20:27 ` GDB BoF notes - GNU Cauldron 2023 John Baldwin
2023-09-29  9:57   ` Pedro Alves
2023-10-06 21:35     ` John Baldwin
2023-09-28 20:44 ` Tom Tromey
2023-09-29  4:48   ` Sam James
2023-09-29 10:25   ` Pedro Alves
2023-10-05  7:08 ` Tom de Vries

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230929092410.u4j5i73bpg5ictyw@octopus \
    --to=lsix@lancelotsix.com \
    --cc=blarsen@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=pedro@palves.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).