* Re: GDB BoF notes - GNU Cauldron 2023
2023-09-27 12:41 GDB BoF notes - GNU Cauldron 2023 Pedro Alves
@ 2023-09-27 13:55 ` Simon Marchi
2023-09-27 14:00 ` Guinevere Larsen
` (3 subsequent siblings)
4 siblings, 0 replies; 13+ messages in thread
From: Simon Marchi @ 2023-09-27 13:55 UTC (permalink / raw)
To: Pedro Alves, gdb
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: GDB BoF notes - GNU Cauldron 2023
2023-09-27 12:41 GDB BoF notes - GNU Cauldron 2023 Pedro Alves
2023-09-27 13:55 ` Simon Marchi
@ 2023-09-27 14:00 ` Guinevere Larsen
2023-09-29 9:24 ` Lancelot SIX
2023-09-27 20:27 ` GDB BoF notes - GNU Cauldron 2023 John Baldwin
` (2 subsequent siblings)
4 siblings, 1 reply; 13+ messages in thread
From: Guinevere Larsen @ 2023-09-27 14:00 UTC (permalink / raw)
To: Pedro Alves, gdb
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: GDB BoF notes - GNU Cauldron 2023
2023-09-27 14:00 ` Guinevere Larsen
@ 2023-09-29 9:24 ` Lancelot SIX
2023-09-29 9:52 ` Turn history saving on by default? (Re: GDB BoF notes - GNU Cauldron 2023) Pedro Alves
0 siblings, 1 reply; 13+ messages in thread
From: Lancelot SIX @ 2023-09-29 9:24 UTC (permalink / raw)
To: Guinevere Larsen; +Cc: Pedro Alves, 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
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Turn history saving on by default? (Re: GDB BoF notes - GNU Cauldron 2023)
2023-09-29 9:24 ` Lancelot SIX
@ 2023-09-29 9:52 ` Pedro Alves
2023-09-29 10:30 ` Guinevere Larsen
0 siblings, 1 reply; 13+ messages in thread
From: Pedro Alves @ 2023-09-29 9:52 UTC (permalink / raw)
To: Lancelot SIX, Guinevere Larsen; +Cc: gdb
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: Turn history saving on by default? (Re: GDB BoF notes - GNU Cauldron 2023)
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
0 siblings, 0 replies; 13+ messages in thread
From: Guinevere Larsen @ 2023-09-29 10:30 UTC (permalink / raw)
To: Pedro Alves, Lancelot SIX; +Cc: gdb
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB BoF notes - GNU Cauldron 2023
2023-09-27 12:41 GDB BoF notes - GNU Cauldron 2023 Pedro Alves
2023-09-27 13:55 ` Simon Marchi
2023-09-27 14:00 ` Guinevere Larsen
@ 2023-09-27 20:27 ` John Baldwin
2023-09-29 9:57 ` Pedro Alves
2023-09-28 20:44 ` Tom Tromey
2023-10-05 7:08 ` Tom de Vries
4 siblings, 1 reply; 13+ messages in thread
From: John Baldwin @ 2023-09-27 20:27 UTC (permalink / raw)
To: Pedro Alves, gdb
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB BoF notes - GNU Cauldron 2023
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
0 siblings, 1 reply; 13+ messages in thread
From: Pedro Alves @ 2023-09-29 9:57 UTC (permalink / raw)
To: John Baldwin, gdb
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB BoF notes - GNU Cauldron 2023
2023-09-29 9:57 ` Pedro Alves
@ 2023-10-06 21:35 ` John Baldwin
0 siblings, 0 replies; 13+ messages in thread
From: John Baldwin @ 2023-10-06 21:35 UTC (permalink / raw)
To: Pedro Alves, gdb
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB BoF notes - GNU Cauldron 2023
2023-09-27 12:41 GDB BoF notes - GNU Cauldron 2023 Pedro Alves
` (2 preceding siblings ...)
2023-09-27 20:27 ` GDB BoF notes - GNU Cauldron 2023 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
4 siblings, 2 replies; 13+ messages in thread
From: Tom Tromey @ 2023-09-28 20:44 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb
>>>>> "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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: GDB BoF notes - GNU Cauldron 2023
2023-09-28 20:44 ` Tom Tromey
@ 2023-09-29 4:48 ` Sam James
2023-09-29 10:25 ` Pedro Alves
1 sibling, 0 replies; 13+ messages in thread
From: Sam James @ 2023-09-29 4:48 UTC (permalink / raw)
To: Tom Tromey; +Cc: Pedro Alves, gdb
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB BoF notes - GNU Cauldron 2023
2023-09-28 20:44 ` Tom Tromey
2023-09-29 4:48 ` Sam James
@ 2023-09-29 10:25 ` Pedro Alves
1 sibling, 0 replies; 13+ messages in thread
From: Pedro Alves @ 2023-09-29 10:25 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb
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".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB BoF notes - GNU Cauldron 2023
2023-09-27 12:41 GDB BoF notes - GNU Cauldron 2023 Pedro Alves
` (3 preceding siblings ...)
2023-09-28 20:44 ` Tom Tromey
@ 2023-10-05 7:08 ` Tom de Vries
4 siblings, 0 replies; 13+ messages in thread
From: Tom de Vries @ 2023-10-05 7:08 UTC (permalink / raw)
To: Pedro Alves, gdb, Lancelot SIX
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.
>
^ permalink raw reply [flat|nested] 13+ messages in thread