public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: John Baldwin <jhb@FreeBSD.org>
To: Pedro Alves <pedro@palves.net>, gdb@sourceware.org
Subject: Re: GDB BoF notes - GNU Cauldron 2023
Date: Wed, 27 Sep 2023 13:27:58 -0700	[thread overview]
Message-ID: <453315e3-2483-7a1d-6ecc-23adc7d24fd3@FreeBSD.org> (raw)
In-Reply-To: <1e26c71e-e242-de11-a687-46e05586e608@palves.net>

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


  parent reply	other threads:[~2023-09-27 20:28 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
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 ` John Baldwin [this message]
2023-09-29  9:57   ` GDB BoF notes - GNU Cauldron 2023 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=453315e3-2483-7a1d-6ecc-23adc7d24fd3@FreeBSD.org \
    --to=jhb@freebsd.org \
    --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).