From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JpI7NRGtEWS9HBAAWB0awg (envelope-from ) for ; Wed, 15 Mar 2023 07:33:37 -0400 Received: by simark.ca (Postfix, from userid 112) id C7D031E223; Wed, 15 Mar 2023 07:33:37 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=fvTN0S+u; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id BA5D61E0D3 for ; Wed, 15 Mar 2023 07:33:36 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3E9313858281 for ; Wed, 15 Mar 2023 11:33:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3E9313858281 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678880015; bh=kj5AynstjKMfdKTtIA6g0HM8ZlIyoOocLPU5lGYVg0A=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=fvTN0S+umzzLVGsrIizAzQO7TBEUwp2EsoBOhj3gFvvPG28onEMr6o9rNqthui5j7 hfBcbVwZH6wqwGQCD8MGEyjr2XOhjH5dq+aCTJFb8zlKchTUvlLbvVr04ztg86GCW4 a6ZGYha6lcm3+syIIT0Ch2e5yK8tVsy16fx5GHWc= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 4459D3858D33 for ; Wed, 15 Mar 2023 11:33:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4459D3858D33 Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-376-yrzw1fysPkKKKrCvx8rlGg-1; Wed, 15 Mar 2023 07:33:06 -0400 X-MC-Unique: yrzw1fysPkKKKrCvx8rlGg-1 Received: by mail-ed1-f70.google.com with SMTP id k12-20020a50c8cc000000b004accf30f6d3so26499913edh.14 for ; Wed, 15 Mar 2023 04:33:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678879985; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kj5AynstjKMfdKTtIA6g0HM8ZlIyoOocLPU5lGYVg0A=; b=F56D6GqOtK3NJqBpi3RSNZxSHuMind8lva1RVgH64UR7XTBnswAMYCY0EFY8azjgLN VSNlKCQhrxXpBsFtjaHUBjz1a7CeZNueAa/PjJnUhAkPjATckH3WVyljfszyH1X0X9nU jb/+WpF6jhgOUYU5m2g+IUytKXAMi/plRyzY68/RNV7lCb3cdLWWB8KOv4lUrMzOzoWY PQWMMbWscjzNXngBI/boEJUG7MxvvZPFNL3sDdhR/ku8blXG+lhJ9WKC+IwbnBoN4/dl DoJEIQafPmhW9GvbgiWWOnKsa+nPo6G7ye7mkvoqJGxBGbztO+qwgu7O4Pw/eu19ojWp 4qLg== X-Gm-Message-State: AO0yUKV0feHKYciWgpq0ueOWB+Ryn4AFWHQC9NINHbr90uCzpdi2nlek 4KhkFcrSFD+ZfhNANLF9C2KcD9mUmF1W8jKrD7IXzWb6ZgN9UtR4pE4RuPKer1bReyzwkyhwZ5k mYCpsttO0E71+FjqIAP4= X-Received: by 2002:a17:906:a895:b0:909:385:da4a with SMTP id ha21-20020a170906a89500b009090385da4amr6160829ejb.54.1678879985480; Wed, 15 Mar 2023 04:33:05 -0700 (PDT) X-Google-Smtp-Source: AK7set/NZQuoqwCC14dwL+nlTdVeWGoNmryvEDSnJTghVrSMIgjMb1xJLxvYaX2IRiGNEFwIdeP0Mg== X-Received: by 2002:a17:906:a895:b0:909:385:da4a with SMTP id ha21-20020a170906a89500b009090385da4amr6160810ejb.54.1678879985178; Wed, 15 Mar 2023 04:33:05 -0700 (PDT) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id i23-20020a1709064ed700b008b95c1fe636sm2357472ejv.207.2023.03.15.04.33.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Mar 2023 04:33:04 -0700 (PDT) To: Luis Machado , "gdb@sourceware.org" Subject: Re: Backporting minor fix to older gdb releases In-Reply-To: References: Date: Wed, 15 Mar 2023 11:33:03 +0000 Message-ID: <87bkkufdw0.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Andrew Burgess via Gdb Reply-To: Andrew Burgess Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" Luis Machado via Gdb writes: > I have a small issue (fixed in gdb 13 via commit > 1ba3a3222039eb2576d29c9fd3af444f59fa51d2) that I'd like to backport a > fix to at least gdb 12 and gdb 11. Does that change fix some bug that is always present? Or does the problem only occur in some situations? i.e. are GDB 11/12 broken with QEMU in all cases, or only if QEMU is run in a certain mode? > > I did, however, notice that it is easily backportable to gdb 10 and > gdb 9, versions also affected by the same bug. > > Given the backport is small and helps prevent crashes when connecting > to a QEMU that supports pointer authentication, I'm wondering what > global maintainers think about it. > > If distros want to pick up the fix, they can do so without having to > worry about conflicts. For any back-ports to have use we'd need to make an additional release from those branches, right? I don't know how many distros are going to update to anything other than an actual release. Generally GDB hasn't made additional point releases for anything other than the last major release. I wouldn't object if we did want to do such a thing - but then I likely wouldn't be the one having to do any work - so I'm certainly not going to say we _should_ do such a thing. If we did want to allow such a thing then I would suggest we limit ourselves to only doing this for smallish patches that fix GDB crashes, and which apply relatively cleanly to the release branches. Which is why I asked above for more details about the commit. If what's really happening is that we're fixing GDB to work with QEMU when run in mode X, then I'd say this is less of a fix, and more of a new feature - support QEMU mode X. And I'd suggest we shouldn't get in the habit of back-porting new features, that feels like a bad can of worms to open. But if this problem is more that QEMU changed, and now GDB 9/10/11/12 is just broken with QEMU in every mode, then back-porting begins to sounds more reasonable. Thanks, Andrew