From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id DA8823861825 for ; Wed, 27 Sep 2023 14:00:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DA8823861825 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695823247; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bLQKAxh3q6X+B9nHr+RejxtNFgbYit207XuAp5/NuuQ=; b=cLFmCBGAao/YKwXzvXxHeRc14bd9mvF0fKWUQ5tGj1OJSmsnS8d0tIDtH5RlWuzceudktw w3wkEcvA5fH79qCULVFT+3B2iJFmaCli+6dowRyfAEtwBwKpc7yb0w3PQOIccSS/YPQYBH hpgOfkkOGXwVZpEZW+DVDRgaz4pQ4AM= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-689-_o1uDsPQO-6_Ns8_H2-LtQ-1; Wed, 27 Sep 2023 10:00:46 -0400 X-MC-Unique: _o1uDsPQO-6_Ns8_H2-LtQ-1 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-9a9e12a3093so969618066b.0 for ; Wed, 27 Sep 2023 07:00:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695823244; x=1696428044; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bLQKAxh3q6X+B9nHr+RejxtNFgbYit207XuAp5/NuuQ=; b=KDCGim9WmDdLvcmIRRoOTS+6aOQd+Eq4JUS+RN868XV5dkKlrxHlExSHtkJa1nKKdF UoF9C/apdbfYA2qa5Mrz90Y2TiJ1iohNSFU8S72xsu42KVcbq73m364N7zzFk8yjyxZQ PeBQpaFlkiSTdJkJKbpPFhEGktyZh/SvnBrgqbDlV2IOzOAVApLOrXRnsSmlTcc0KSsK UT4k+AlNAU4S9T+SBMxshlGJgG59NhUkeApdZF/+5oyTExaMzFigQlSOTKWhRy2u90wB 2xAtlfHCPEJ9w0kji/zlNX785zYXyepN13BzmZv8gzhdpz3uxIHUkV4tiI23HAMhc54O 3EqA== X-Gm-Message-State: AOJu0YzQtLySbv8bGPz9o2FMUSMv4BUUvxaPINlMlQesa4IylfuTeM+8 nEbb3fGqJ4k41g+K20FvOA3dMwXnzEVbPYfvs8PhomS1ASKWXGLlOUtnE8+zDIUcQ8QVgHYWLRj viCdw3Otjg2sQnMcLK0o= X-Received: by 2002:a17:906:8a64:b0:9ae:659f:4d2f with SMTP id hy4-20020a1709068a6400b009ae659f4d2fmr3010446ejc.26.1695823244746; Wed, 27 Sep 2023 07:00:44 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF0Sjs71HkbnvYhSREjN3vw9XQ1CnN8MQoUSw6qP22c0TjItGh/czqvCXnXxgizqg3aZu1oJA== X-Received: by 2002:a17:906:8a64:b0:9ae:659f:4d2f with SMTP id hy4-20020a1709068a6400b009ae659f4d2fmr3010405ejc.26.1695823244363; Wed, 27 Sep 2023 07:00:44 -0700 (PDT) Received: from [192.168.0.129] (ip-94-112-227-180.bb.vodafone.cz. [94.112.227.180]) by smtp.gmail.com with ESMTPSA id g27-20020a170906349b00b0099bc0daf3d7sm9290006ejb.182.2023.09.27.07.00.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Sep 2023 07:00:44 -0700 (PDT) Message-ID: <19c57e96-288e-1954-c211-93fc4b22b43e@redhat.com> Date: Wed, 27 Sep 2023 16:00:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: GDB BoF notes - GNU Cauldron 2023 To: Pedro Alves , gdb@sourceware.org References: <1e26c71e-e242-de11-a687-46e05586e608@palves.net> From: Guinevere Larsen In-Reply-To: <1e26c71e-e242-de11-a687-46e05586e608@palves.net> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 (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