GDB BoF notes - GNU Cauldron 2023

GDB BoF notes - GNU Cauldron 2023

[Pedro Alves]

Hi all,

We had a GDB BoF at the GNU Cauldron this past weekend, like in
previous years.

I was positively surprised with the attendance and the engagement.
Thanks all!

I took notes live while we were discussing.  Thanks to Mark Wielaard
for letting me use this computer.  :-)

Below's an edited version of the notes, with some more details filled
in.

=========== GDB BoF / GNU Cauldron 2023 ===============

- Testsuite and CI discussion

  With either Linaro's CI and the sourceware.org buildbot, pre-commit,
  post-commit, should breakages result in emails to mailing list?

  Are post-commit breakage emails sent to git author only?  Should go
  to git committer as well, for e.g., the scenario of a maintainer
  applying a non-maintainer's patch.  AI: Talk with Maxim Kuvyrkov
  about it.

  Be mindful of overwhelming gdb-testers traffic.  Counter argument
  raised -- list is also used as results archive.

- Can we require C++17?

  Lancelot has patches for this.

  Looked at / discussed policy established when we migrated to C++11:
   https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F

     "Our general policy is to wait until the oldest compiler that
      supports C++NN is at least 3 years old."

  Discussion about whether the bump is problematic for current
  distros.

  Looked for first GCC version that claims supports C++17.  In GCC 9
  release notes: "The C++17 implementation is no longer experimental."
  GCC 9.1 was released on May 3, 2019.

  Do we need full C++17, though?  We can use language features even if
  the standard library implementation doesn't support everything.

  Were there actual ABI breakages between compiler releases before it
  was made non-experimental, though?  AI: ask Jonathan Wakely.

  On whether we have easy availability of a new enough compiler in
  distros, in practice:

  - Tom de Vries to double check for SuSE.

  - Carlos O'Donell confirms that for RHEL we're good, because of GCC
    Toolset.

  - Someone should check Debian/Ubuntu and others.

  - BSDs tend to have easy access to recent Clang.

  - MinGW toolchains tend to use newer GCCs.

- Patch review/approval mechanisms

  How to tag approval for just parts you're responsible for?  

  #1 Add subsystem in parens after approved-by?

     Approved-by: John Doe <john@acme.org> (docs)

  #2 Alternative discussed which had most consensus:

     Use "Approved-by" for whole patch approval.

     Use "Acked-by" for partial/subsystem approval.

  Discussion on acked-by (linux kernel: partial approval for
  subsystem).

  Alternative probably better for tooling, like b4.  People nervous
  about extra tags breaking those.

  Gwen takes action item to bring this up on the list.

- Security policy.  

  Piggy back on binutils policy?

  GDB can do lots of potentially unsafe things, need to containerize.

  What about GDB remote protocol?  Must be a considered a trusted
  connection, users are responsible for
  security/authentication/encryption.

  qemu policy:

    https://www.qemu.org/docs/master/system/gdb.html

    "Connecting to the GDB socket allows running arbitrary code inside
    the guest; in case of the TCG emulation, which is not considered a
    security boundary, this also means running arbitrary code on the
    host. Additionally, when debugging qemu-user, it allows directly
    downloading any file readable by QEMU from the host."

  AI: Sid and Andrew already working on policy.

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

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

Re: GDB BoF notes - GNU Cauldron 2023

[Simon Marchi]

On 9/27/23 08:41, Pedro Alves wrote:
> Hi all,
> 
> We had a GDB BoF at the GNU Cauldron this past weekend, like in
> previous years.
> 
> I was positively surprised with the attendance and the engagement.
> Thanks all!
> 
> I took notes live while we were discussing.  Thanks to Mark Wielaard
> for letting me use this computer.  :-)
> 
> Below's an edited version of the notes, with some more details filled
> in.

Thanks a lot for taking notes!

> =========== GDB BoF / GNU Cauldron 2023 ===============
> 
> - Testsuite and CI discussion
> 
>   With either Linaro's CI and the sourceware.org buildbot, pre-commit,
>   post-commit, should breakages result in emails to mailing list?
> 
>   Are post-commit breakage emails sent to git author only?  Should go
>   to git committer as well, for e.g., the scenario of a maintainer
>   applying a non-maintainer's patch.  AI: Talk with Maxim Kuvyrkov
>   about it.
> 
>   Be mindful of overwhelming gdb-testers traffic.  Counter argument
>   raised -- list is also used as results archive.

If we decide not to send the breakage emails to gdb-patches, could we
have a list we can subscribe to, to receive breakage emails?

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

I would be happy for these two changes to defaults to be made.

Simon

Re: GDB BoF notes - GNU Cauldron 2023

[Guinevere Larsen]

On 27/09/2023 14:41, Pedro Alves wrote:
> Hi all,
>
> We had a GDB BoF at the GNU Cauldron this past weekend, like in
> previous years.
>
> I was positively surprised with the attendance and the engagement.
> Thanks all!
>
> I took notes live while we were discussing.  Thanks to Mark Wielaard
> for letting me use this computer.  :-)
>
> Below's an edited version of the notes, with some more details filled
> in.
>
> =========== GDB BoF / GNU Cauldron 2023 ===============
>
> - Testsuite and CI discussion
>
>    With either Linaro's CI and the sourceware.org buildbot, pre-commit,
>    post-commit, should breakages result in emails to mailing list?
>
>    Are post-commit breakage emails sent to git author only?  Should go
>    to git committer as well, for e.g., the scenario of a maintainer
>    applying a non-maintainer's patch.  AI: Talk with Maxim Kuvyrkov
>    about it.
>
>    Be mindful of overwhelming gdb-testers traffic.  Counter argument
>    raised -- list is also used as results archive.
>
> - Can we require C++17?
>
>    Lancelot has patches for this.
>
>    Looked at / discussed policy established when we migrated to C++11:
>     https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F
>
>       "Our general policy is to wait until the oldest compiler that
>        supports C++NN is at least 3 years old."
>
>    Discussion about whether the bump is problematic for current
>    distros.
>
>    Looked for first GCC version that claims supports C++17.  In GCC 9
>    release notes: "The C++17 implementation is no longer experimental."
>    GCC 9.1 was released on May 3, 2019.
>
>    Do we need full C++17, though?  We can use language features even if
>    the standard library implementation doesn't support everything.
>
>    Were there actual ABI breakages between compiler releases before it
>    was made non-experimental, though?  AI: ask Jonathan Wakely.
>
>    On whether we have easy availability of a new enough compiler in
>    distros, in practice:
>
>    - Tom de Vries to double check for SuSE.
>
>    - Carlos O'Donell confirms that for RHEL we're good, because of GCC
>      Toolset.
>
>    - Someone should check Debian/Ubuntu and others.
>
>    - BSDs tend to have easy access to recent Clang.
>
>    - MinGW toolchains tend to use newer GCCs.
>
> - Patch review/approval mechanisms
>
>    How to tag approval for just parts you're responsible for?
>
>    #1 Add subsystem in parens after approved-by?
>
>       Approved-by: John Doe <john@acme.org> (docs)
>
>    #2 Alternative discussed which had most consensus:
>
>       Use "Approved-by" for whole patch approval.
>
>       Use "Acked-by" for partial/subsystem approval.
>
>    Discussion on acked-by (linux kernel: partial approval for
>    subsystem).
>
>    Alternative probably better for tooling, like b4.  People nervous
>    about extra tags breaking those.
>
>    Gwen takes action item to bring this up on the list.
I'm reworking my old patch, should be going to the mailing list early 
next week.
>
> - Security policy.
>
>    Piggy back on binutils policy?
>
>    GDB can do lots of potentially unsafe things, need to containerize.
>
>    What about GDB remote protocol?  Must be a considered a trusted
>    connection, users are responsible for
>    security/authentication/encryption.
>
>    qemu policy:
>
>      https://www.qemu.org/docs/master/system/gdb.html
>
>      "Connecting to the GDB socket allows running arbitrary code inside
>      the guest; in case of the TCG emulation, which is not considered a
>      security boundary, this also means running arbitrary code on the
>      host. Additionally, when debugging qemu-user, it allows directly
>      downloading any file readable by QEMU from the host."
>
>    AI: Sid and Andrew already working on policy.
>
> - 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.

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

Re: GDB BoF notes - GNU Cauldron 2023

[John Baldwin]

On 9/27/23 1:41 PM, Pedro Alves wrote:
> - Can we require C++17?
> 
>    Lancelot has patches for this.
> 
>    Looked at / discussed policy established when we migrated to C++11:
>     https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F
> 
>       "Our general policy is to wait until the oldest compiler that
>        supports C++NN is at least 3 years old."
> 
>    Discussion about whether the bump is problematic for current
>    distros.
> 
>    Looked for first GCC version that claims supports C++17.  In GCC 9
>    release notes: "The C++17 implementation is no longer experimental."
>    GCC 9.1 was released on May 3, 2019.
> 
>    Do we need full C++17, though?  We can use language features even if
>    the standard library implementation doesn't support everything.
> 
>    Were there actual ABI breakages between compiler releases before it
>    was made non-experimental, though?  AI: ask Jonathan Wakely.
> 
>    On whether we have easy availability of a new enough compiler in
>    distros, in practice:
> 
>    - Tom de Vries to double check for SuSE.
> 
>    - Carlos O'Donell confirms that for RHEL we're good, because of GCC
>      Toolset.
> 
>    - Someone should check Debian/Ubuntu and others.
> 
>    - BSDs tend to have easy access to recent Clang.

Confirming this point.  Lancelot had asked me about this earlier and all
of the BSD's have succifient clang or GCC in relevant releases.

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

+1 to both of these.  One caveat about the pagination case is that I
use custom commands that can sometimes generate a lot of output (e.g.
walking linked-lists in a kernel crash image outputting info about
each entry, or similar things for entries in descriptor rings).  If one
of these scripts has a bug that causes an infinite loop, the pager
seems to be the only way to stop the command.  In particular, Ctrl-C
doesn't work in my experience to cancel a user command stuck in an
infinite loop.  It might be nice to ensure that Ctrl-C can cancel both
user and builtin commands that are either stuck or generating reams of
output.

-- 
John Baldwin

Re: GDB BoF notes - GNU Cauldron 2023

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:

Pedro> - Revisiting defaults

Pedro>   - Can we turn history saving on by default?  Maybe default to
Pedro>     history on home dir by default, too (~/.gdb_history).  That would
Pedro>     align us with bash.

Maybe some XDG directory?

Anyway +1 for this from me.

Pedro>   - Can we disable pagination by default?  Surprisingly, no one in the
Pedro>     room expressed that they like pagination on.

I leave it on but I can't say I really like it.  Mostly I suppose it's a
distraction and I just haven't bothered changing it.

Pedro>       "(gdb) pipe GDB_COMMAND | less"

I wonder if "with pagination on" works too.

Anyway +1 on this too.


Some other defaults to consider:

set print object on
set breakpoint pending on
set print pretty on

The last one is iffy I guess, maybe people like the compact output.  The
first two I think I've had to tell many people about over the years.

Tom

Re: GDB BoF notes - GNU Cauldron 2023

[Sam James]

Tom Tromey <tom@tromey.com> writes:

>>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:
>
> Pedro> - Revisiting defaults
>
> Pedro>   - Can we turn history saving on by default?  Maybe default to
> Pedro>     history on home dir by default, too (~/.gdb_history).  That would
> Pedro>     align us with bash.
>
> Maybe some XDG directory?
>
> Anyway +1 for this from me.

Yes, please. I like Guinevere's idea of possibly allowing to separate
per session but I don't personally see it as a blocker (it's never
bothered me much).

>
> Pedro>   - Can we disable pagination by default?  Surprisingly, no one in the
> Pedro>     room expressed that they like pagination on.
>
> I leave it on but I can't say I really like it.  Mostly I suppose it's a
> distraction and I just haven't bothered changing it.
>
> Pedro>       "(gdb) pipe GDB_COMMAND | less"
>
> I wonder if "with pagination on" works too.
>
> Anyway +1 on this too.
>
>
> Some other defaults to consider:
>
> set print object on
> set breakpoint pending on
> set print pretty on
>
> The last one is iffy I guess, maybe people like the compact output.  The
> first two I think I've had to tell many people about over the years.

I've had to start putting a lot of these on our wiki because it's so
hard to find them / realise they're super useful.

>
> Tom

Re: GDB BoF notes - GNU Cauldron 2023

[Lancelot SIX]

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

Turn history saving on by default? (Re: GDB BoF notes - GNU Cauldron 2023)

[Pedro Alves]

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.

Re: GDB BoF notes - GNU Cauldron 2023

[Pedro Alves]

On 2023-09-27 21:27, John Baldwin wrote:

> +1 to both of these.  One caveat about the pagination case is that I
> use custom commands that can sometimes generate a lot of output (e.g.
> walking linked-lists in a kernel crash image outputting info about
> each entry, or similar things for entries in descriptor rings).  If one
> of these scripts has a bug that causes an infinite loop, the pager
> seems to be the only way to stop the command.  In particular, Ctrl-C
> doesn't work in my experience to cancel a user command stuck in an
> infinite loop.  It might be nice to ensure that Ctrl-C can cancel both
> user and builtin commands that are either stuck or generating reams of
> output.
> 

I'm surprised to hear this, as it's already supposed to be possible to
Ctrl-C in those cases.  But I won't be surprised if there's some bug
swallowing Ctrl-C somewhere.  I do recall that Kevin fixed a good number
of them for the SIGTERM propagation patches.  It may also be that it's the
user command that is buggy -- e.g., if it's a python command and then the
command swallows the keyboard interrupt exceptions.

Re: GDB BoF notes - GNU Cauldron 2023

[Pedro Alves]

On 2023-09-28 21:44, Tom Tromey wrote:

> Some other defaults to consider:
> 
> set print object on

+1.  I've wondered before what was the reason for not making this the default.
Maybe because it requires reading the rtti/vtable, and that can go wrong, and
it was thought that when it fails it's confusing?  Dunno.  Things may be better
nowadays in the bad scenarios.  At least you can do "p -o -- var" nowadays,
but I guess most people don't know about that.

> set breakpoint pending on

+1000.  If you get a pending breakpoint due to a typo, you can always delete
the just-created breakpoint...

> set print pretty on
> 
> The last one is iffy I guess, maybe people like the compact output.  The
> first two I think I've had to tell many people about over the years.

Personally I prefer the compact output most of the times, and only occasionally
do "print -pretty" or "with print pretty".

Re: Turn history saving on by default? (Re: GDB BoF notes - GNU Cauldron 2023)

[Guinevere Larsen]

On 29/09/2023 11:52, Pedro Alves wrote:
> 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?
Yeah, those are good points. Any way to fix this is way over-engineering 
compared to just "local histories in each folder".
>
>> 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.
>
Yeah, I think I agree. This can still be over-written by a user that 
wants separate histories, and having mixed ones is better than nothing 
at all. +1 for making 3 the default

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

Re: GDB BoF notes - GNU Cauldron 2023

[Tom de Vries]

On 9/27/23 14:41, Pedro Alves wrote:
> - Can we require C++17?
> 
>    Lancelot has patches for this.
> 
>    Looked at / discussed policy established when we migrated to C++11:
>     https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F
> 
>       "Our general policy is to wait until the oldest compiler that
>        supports C++NN is at least 3 years old."
> 
>    Discussion about whether the bump is problematic for current
>    distros.
> 
>    Looked for first GCC version that claims supports C++17.  In GCC 9
>    release notes: "The C++17 implementation is no longer experimental."
>    GCC 9.1 was released on May 3, 2019.
> 
>    Do we need full C++17, though?  We can use language features even if
>    the standard library implementation doesn't support everything.
> 
>    Were there actual ABI breakages between compiler releases before it
>    was made non-experimental, though?  AI: ask Jonathan Wakely.
> 
>    On whether we have easy availability of a new enough compiler in
>    distros, in practice:
> 
>    - Tom de Vries to double check for SuSE.
> 

I've double-checked, it's not a problem.

I see now that it's mentioned that Lancelot has patches, I missed that 
and submitted an RFC ( 
https://sourceware.org/pipermail/gdb-patches/2023-October/202987.html ).

Thanks,
- Tom

>    - Carlos O'Donell confirms that for RHEL we're good, because of GCC
>      Toolset.
> 
>    - Someone should check Debian/Ubuntu and others.
> 
>    - BSDs tend to have easy access to recent Clang.
> 
>    - MinGW toolchains tend to use newer GCCs.
> 

Re: GDB BoF notes - GNU Cauldron 2023

[John Baldwin]

On 9/29/23 5:57 AM, Pedro Alves wrote:
> On 2023-09-27 21:27, John Baldwin wrote:
> 
>> +1 to both of these.  One caveat about the pagination case is that I
>> use custom commands that can sometimes generate a lot of output (e.g.
>> walking linked-lists in a kernel crash image outputting info about
>> each entry, or similar things for entries in descriptor rings).  If one
>> of these scripts has a bug that causes an infinite loop, the pager
>> seems to be the only way to stop the command.  In particular, Ctrl-C
>> doesn't work in my experience to cancel a user command stuck in an
>> infinite loop.  It might be nice to ensure that Ctrl-C can cancel both
>> user and builtin commands that are either stuck or generating reams of
>> output.
>>
> 
> I'm surprised to hear this, as it's already supposed to be possible to
> Ctrl-C in those cases.  But I won't be surprised if there's some bug
> swallowing Ctrl-C somewhere.  I do recall that Kevin fixed a good number
> of them for the SIGTERM propagation patches.  It may also be that it's the
> user command that is buggy -- e.g., if it's a python command and then the
> command swallows the keyboard interrupt exceptions.

My memory must be a bit fuzzy here, and perhaps this only applied to much
older versions of GDB.  Most of my scripts date back to GDB 6 and thus
are not in python.  I just tried some simple tests against gdb 13 locally
and was able to Ctrl-C custom commands with an infinite loop just fine.

So I'm still a +1 to both suggestions, and no longer have a caveat.

-- 
John Baldwin