public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: Luis Machado <luis.machado@arm.com>,
	"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: Backporting minor fix to older gdb releases
Date: Wed, 15 Mar 2023 11:33:03 +0000	[thread overview]
Message-ID: <87bkkufdw0.fsf@redhat.com> (raw)
In-Reply-To: <b2dc7c5f-d325-92ae-b000-ad6779dc1069@arm.com>

Luis Machado via Gdb <gdb@sourceware.org> 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


  reply	other threads:[~2023-03-15 11:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-14 23:18 Luis Machado
2023-03-15 11:33 ` Andrew Burgess [this message]
2023-03-15 12:26   ` Luis Machado
2023-03-15 13:11     ` Joel Brobecker
2023-03-15 13:45       ` Luis Machado
2023-03-20  4:18         ` Joel Brobecker
2023-03-22  9:57           ` Luis Machado
2023-04-11  6:04             ` Luis Machado

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=87bkkufdw0.fsf@redhat.com \
    --to=aburgess@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=luis.machado@arm.com \
    /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).