Re: Backporting minor fix to older gdb releases

Luis Machado via Gdb <[email protected]> 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