Backporting minor fix to older gdb releases

Backporting minor fix to older gdb releases

[Luis Machado via Gdb]

Hi,

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.

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.

What do you think?

Thanks,
Luis

Re: Backporting minor fix to older gdb releases

[Andrew Burgess via Gdb]

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

Re: Backporting minor fix to older gdb releases

[Luis Machado via Gdb]

On 3/15/23 11:33, Andrew Burgess wrote:
> 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?
> 

The bug has always been there, but it has never manifested because it requires the
target to provide pauth support *and* additional system registers (registers gdb doesn't
care about).

The qemu folks have recently added pauth support to their gdbstub, and for older gdb's (9, 10, 11
and 12), the sight of that pauth feature makes them crash, which is not good.

>>
>> 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.

That is true. My reasoning for backporting this fix all the way to gdb-9 was to
allow package maintainers to easily pick the fix up and apply it without having to
deal with conflicts.

I see Ubuntu 20.04, for example, uses gdb-9. If we were to use it with qemu 8.0.0,
it would crash.

> 
> 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.

This is a fairly small and localized patch, which is why I'm considering it.

> 
> 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.

They will be broken with qemu 8.0.0 for AArch64 when connecting to qemu's gdbstub.

> 
> Thanks,
> Andrew
> 

Re: Backporting minor fix to older gdb releases

[Joel Brobecker via Gdb]

FWIW, there is no real policy that I know of.

We have been known to accept patches on release branches past the .2
release. It's been very rare, though. In all cases, the push was done
with the understanding that there would likely not be another official
release off that branch, so that was purely for the benefit of people
who wanted to build from the HEAD of a release branch rather than from
an official release.

Whether we should be doing it in this case, I don't have a strong
opinion. I think Andrew is making good points, and I'm wondering
whether it will actually serve anyone if we backport the patches.
On the other hand, are the patches extra safe? If they are, perhaps
in the spirit of not standing in the way of someone willing to make
it better for others...

-- 
Joel

Re: Backporting minor fix to older gdb releases

[Luis Machado via Gdb]

On 3/15/23 13:11, Joel Brobecker via Gdb wrote:
> FWIW, there is no real policy that I know of.
> 
> We have been known to accept patches on release branches past the .2
> release. It's been very rare, though. In all cases, the push was done
> with the understanding that there would likely not be another official
> release off that branch, so that was purely for the benefit of people
> who wanted to build from the HEAD of a release branch rather than from
> an official release.
> 
> Whether we should be doing it in this case, I don't have a strong
> opinion. I think Andrew is making good points, and I'm wondering
> whether it will actually serve anyone if we backport the patches.
> On the other hand, are the patches extra safe? If they are, perhaps
> in the spirit of not standing in the way of someone willing to make
> it better for others...
> 

All reasonable points, I agree.

The patch (a single one) is mostly trivial reordering of code to fix a pseudo-register
number that we get wrong for the pauth feature. It helps in that it allows people to use
gdb 9/10/11/12 with a new qemu. Otherwise those gdb's will just crash on connection, with no
way around it.

Re: Backporting minor fix to older gdb releases

[Joel Brobecker via Gdb]

> > FWIW, there is no real policy that I know of.
> > 
> > We have been known to accept patches on release branches past the .2
> > release. It's been very rare, though. In all cases, the push was done
> > with the understanding that there would likely not be another official
> > release off that branch, so that was purely for the benefit of people
> > who wanted to build from the HEAD of a release branch rather than from
> > an official release.
> > 
> > Whether we should be doing it in this case, I don't have a strong
> > opinion. I think Andrew is making good points, and I'm wondering
> > whether it will actually serve anyone if we backport the patches.
> > On the other hand, are the patches extra safe? If they are, perhaps
> > in the spirit of not standing in the way of someone willing to make
> > it better for others...
> > 
> 
> All reasonable points, I agree.
> 
> The patch (a single one) is mostly trivial reordering of code to fix a
> pseudo-register number that we get wrong for the pauth feature. It
> helps in that it allows people to use gdb 9/10/11/12 with a new qemu.
> Otherwise those gdb's will just crash on connection, with no way
> around it.

This part I understood. The part I wasn't sure about is whether
there was any known entity that would pick the branch update up,
and rebuild with it.

Nevertheless, this is not critical at all. As long as the patch
is extra safe (which it looks like it can't possibly cause things
to be worse, except in the pauth case which is already crashing),
I don't see a reason why we should block the patch's inclusion
in our older branches. You can go right ahead.

-- 
Joel

Re: Backporting minor fix to older gdb releases

[Luis Machado via Gdb]

On 3/20/23 04:18, Joel Brobecker wrote:
>>> FWIW, there is no real policy that I know of.
>>>
>>> We have been known to accept patches on release branches past the .2
>>> release. It's been very rare, though. In all cases, the push was done
>>> with the understanding that there would likely not be another official
>>> release off that branch, so that was purely for the benefit of people
>>> who wanted to build from the HEAD of a release branch rather than from
>>> an official release.
>>>
>>> Whether we should be doing it in this case, I don't have a strong
>>> opinion. I think Andrew is making good points, and I'm wondering
>>> whether it will actually serve anyone if we backport the patches.
>>> On the other hand, are the patches extra safe? If they are, perhaps
>>> in the spirit of not standing in the way of someone willing to make
>>> it better for others...
>>>
>>
>> All reasonable points, I agree.
>>
>> The patch (a single one) is mostly trivial reordering of code to fix a
>> pseudo-register number that we get wrong for the pauth feature. It
>> helps in that it allows people to use gdb 9/10/11/12 with a new qemu.
>> Otherwise those gdb's will just crash on connection, with no way
>> around it.
> 
> This part I understood. The part I wasn't sure about is whether
> there was any known entity that would pick the branch update up,
> and rebuild with it.

I was thinking the main distros would pick it up (but can't be sure they will).

> 
> Nevertheless, this is not critical at all. As long as the patch
> is extra safe (which it looks like it can't possibly cause things
> to be worse, except in the pauth case which is already crashing),
> I don't see a reason why we should block the patch's inclusion
> in our older branches. You can go right ahead.
> 

Thanks Joel. I'll do this over the course of the week/next week.

Re: Backporting minor fix to older gdb releases

[Luis Machado via Gdb]

Hi,

On 3/22/23 09:57, Luis Machado via Gdb wrote:
> On 3/20/23 04:18, Joel Brobecker wrote:
>>>> FWIW, there is no real policy that I know of.
>>>>
>>>> We have been known to accept patches on release branches past the .2
>>>> release. It's been very rare, though. In all cases, the push was done
>>>> with the understanding that there would likely not be another official
>>>> release off that branch, so that was purely for the benefit of people
>>>> who wanted to build from the HEAD of a release branch rather than from
>>>> an official release.
>>>>
>>>> Whether we should be doing it in this case, I don't have a strong
>>>> opinion. I think Andrew is making good points, and I'm wondering
>>>> whether it will actually serve anyone if we backport the patches.
>>>> On the other hand, are the patches extra safe? If they are, perhaps
>>>> in the spirit of not standing in the way of someone willing to make
>>>> it better for others...
>>>>
>>>
>>> All reasonable points, I agree.
>>>
>>> The patch (a single one) is mostly trivial reordering of code to fix a
>>> pseudo-register number that we get wrong for the pauth feature. It
>>> helps in that it allows people to use gdb 9/10/11/12 with a new qemu.
>>> Otherwise those gdb's will just crash on connection, with no way
>>> around it.
>>
>> This part I understood. The part I wasn't sure about is whether
>> there was any known entity that would pick the branch update up,
>> and rebuild with it.
> 
> I was thinking the main distros would pick it up (but can't be sure they will).
> 
>>
>> Nevertheless, this is not critical at all. As long as the patch
>> is extra safe (which it looks like it can't possibly cause things
>> to be worse, except in the pauth case which is already crashing),
>> I don't see a reason why we should block the patch's inclusion
>> in our older branches. You can go right ahead.
>>
> 
> Thanks Joel. I'll do this over the course of the week/next week.

The qemu devs have decided to postpone the change that would've caused older gdb's to break.

We're now discussing side-stepping older gdb's by making qemu and gdb exchange the same information
via a different xml feature string.

Given the above, I decided to drop the backports idea.