From: Pedro Alves <pedro@palves.net>
To: gdb@sourceware.org
Subject: GDB BoF notes - GNU Cauldron 2023
Date: Wed, 27 Sep 2023 13:41:47 +0100 [thread overview]
Message-ID: <1e26c71e-e242-de11-a687-46e05586e608@palves.net> (raw)
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.
next reply other threads:[~2023-09-27 12:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-27 12:41 Pedro Alves [this message]
2023-09-27 13:55 ` Simon Marchi
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
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=1e26c71e-e242-de11-a687-46e05586e608@palves.net \
--to=pedro@palves.net \
--cc=gdb@sourceware.org \
/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).