Re: GDB BoF notes - GNU Cauldron 2023

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 <[email protected]> (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