Backport 037e8112b97 for the 10.x branch

Backport 037e8112b97 for the 10.x branch

[Emil Velikov]

Greetings Joel, all,

I'd like to nominate a patch for the 10.x branch, in particular
037e8112b97 ("[gdb/server] Don't overwrite fs/gs_base with -m32").
Since I just missed 10.2 - it would be great if we can have it in the
next bugfix release.

As the commit suggests, without the fix gdbserver is virtually
unusable for any 32bit application.

Thanks in advance and apologies if this isn't the correct format for
such a request.
-Emil

[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff_plain;h=037e8112b9794a633248e5aa5943f3be273e0a20

Re: Backport 037e8112b97 for the 10.x branch

[Joel Brobecker]

Hi Emil,

On Sun, May 16, 2021 at 03:00:06PM +0100, Emil Velikov wrote:
> Greetings Joel, all,
> 
> I'd like to nominate a patch for the 10.x branch, in particular
> 037e8112b97 ("[gdb/server] Don't overwrite fs/gs_base with -m32").
> Since I just missed 10.2 - it would be great if we can have it in the
> next bugfix release.

We are not planning on doing another 10.x release, so would that
still be useful for you to do?

Note that we're started the process of preparing for the GDB 11.1
release. It's really hard to predict how long it's going to take
before we release, considering that we are a volunteer project,
but I'm hoping a couple of months.

> As the commit suggests, without the fix gdbserver is virtually
> unusable for any 32bit application.
> 
> Thanks in advance and apologies if this isn't the correct format for
> such a request.
> -Emil
> 
> [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff_plain;h=037e8112b9794a633248e5aa5943f3be273e0a20

-- 
Joel

Re: Backport 037e8112b97 for the 10.x branch

[Emil Velikov]

Hi Joel,

Thanks for the prompt reply

On Mon, 17 May 2021 at 17:21, Joel Brobecker <brobecke@adacore.com> wrote:
>
> Hi Emil,
>
> On Sun, May 16, 2021 at 03:00:06PM +0100, Emil Velikov wrote:
> > Greetings Joel, all,
> >
> > I'd like to nominate a patch for the 10.x branch, in particular
> > 037e8112b97 ("[gdb/server] Don't overwrite fs/gs_base with -m32").
> > Since I just missed 10.2 - it would be great if we can have it in the
> > next bugfix release.
>
> We are not planning on doing another 10.x release, so would that
> still be useful for you to do?
>
Yes, it would.

> Note that we're started the process of preparing for the GDB 11.1
> release. It's really hard to predict how long it's going to take
> before we release, considering that we are a volunteer project,
> but I'm hoping a couple of months.
>
Realising that I'm pushing my luck, I would warmly encourage you to do
another 10.x release.
Partially due to the severity of the bug - anything built with -m32 is
affected - and partially due to how wide-spread the 10.x series is.

From a casual look at repology [1] the following distributions are
affected and a bunch of them will be "stuck" with the 10.x series.
Thus I do think it will be of great benefit in having another 10.x
with said fix - even if only this patch is included.

List of distributions using GDB 10.x alongside 5.9+ kernel - Alpine,
Arch, Debian testing, Fedora 33&34, openSUSE Leap 15.x, Ubuntu 21.04
... and their respective derivatives.

Thanks for your time and dedication improving GDB.
-Emil

[1] https://repology.org/project/gdb/versions

Re: Backport 037e8112b97 for the 10.x branch

[Joel Brobecker]

> > We are not planning on doing another 10.x release, so would that
> > still be useful for you to do?
> >
> Yes, it would.
> 
> > Note that we're started the process of preparing for the GDB 11.1
> > release. It's really hard to predict how long it's going to take
> > before we release, considering that we are a volunteer project,
> > but I'm hoping a couple of months.
> >
> Realising that I'm pushing my luck, I would warmly encourage you to do
> another 10.x release.
> Partially due to the severity of the bug - anything built with -m32 is
> affected - and partially due to how wide-spread the 10.x series is.
> 
> >From a casual look at repology [1] the following distributions are
> affected and a bunch of them will be "stuck" with the 10.x series.
> Thus I do think it will be of great benefit in having another 10.x
> with said fix - even if only this patch is included.
> 
> List of distributions using GDB 10.x alongside 5.9+ kernel - Alpine,
> Arch, Debian testing, Fedora 33&34, openSUSE Leap 15.x, Ubuntu 21.04
> ... and their respective derivatives.
> 
> Thanks for your time and dedication improving GDB.

Typically, Linux distributions build a modified version of GDB,
with a number of addition patches. So, while I'm open to the idea
of creating another corrective release in general, I'm not certain
we have a sufficiently strong reason in this case. If there is
a stronger push, perhaps...

In the meantime, if you'd like, you can certainly ask on the gdb-patches
mailing-list for permission to backport this patch to the gdb-10-branch.
If given, before you can backport it, you'll need to create a GDB PR
in bugzilla (https://sourceware.org/bugzilla/) so as to document this
issue, and then ammend the commit message to include that PR number,
e.g. like this commit:

    | gdb/ChangeLog:
    |
    |         PR gdb/27614
    |         * contrib/gdb-add-index.sh: Fix when called with a symlink as an
    |         argument.

We'll also need to ask someone to create a 10.3 milestone and
set the Target Milestone field to that new milestone.

The PR is there to help us track precisely what changes went in
the various corrective releases, and doing the above is part of
our procedures for backporting changes to those corrective releases.

-- 
Joel

Re: Backport 037e8112b97 for the 10.x branch

[Emil Velikov]

On Fri, 21 May 2021 at 21:01, Joel Brobecker <brobecke@adacore.com> wrote:
>
> > > We are not planning on doing another 10.x release, so would that
> > > still be useful for you to do?
> > >
> > Yes, it would.
> >
> > > Note that we're started the process of preparing for the GDB 11.1
> > > release. It's really hard to predict how long it's going to take
> > > before we release, considering that we are a volunteer project,
> > > but I'm hoping a couple of months.
> > >
> > Realising that I'm pushing my luck, I would warmly encourage you to do
> > another 10.x release.
> > Partially due to the severity of the bug - anything built with -m32 is
> > affected - and partially due to how wide-spread the 10.x series is.
> >
> > >From a casual look at repology [1] the following distributions are
> > affected and a bunch of them will be "stuck" with the 10.x series.
> > Thus I do think it will be of great benefit in having another 10.x
> > with said fix - even if only this patch is included.
> >
> > List of distributions using GDB 10.x alongside 5.9+ kernel - Alpine,
> > Arch, Debian testing, Fedora 33&34, openSUSE Leap 15.x, Ubuntu 21.04
> > ... and their respective derivatives.
> >
> > Thanks for your time and dedication improving GDB.
>
> Typically, Linux distributions build a modified version of GDB,
> with a number of addition patches. So, while I'm open to the idea
> of creating another corrective release in general, I'm not certain
> we have a sufficiently strong reason in this case. If there is
> a stronger push, perhaps...
>
> In the meantime, if you'd like, you can certainly ask on the gdb-patches
> mailing-list for permission to backport this patch to the gdb-10-branch.
> If given, before you can backport it, you'll need to create a GDB PR
> in bugzilla (https://sourceware.org/bugzilla/) so as to document this
> issue, and then ammend the commit message to include that PR number,
> e.g. like this commit:
>
>     | gdb/ChangeLog:
>     |
>     |         PR gdb/27614
>     |         * contrib/gdb-add-index.sh: Fix when called with a symlink as an
>     |         argument.
>
> We'll also need to ask someone to create a 10.3 milestone and
> set the Target Milestone field to that new milestone.
>
> The PR is there to help us track precisely what changes went in
> the various corrective releases, and doing the above is part of
> our procedures for backporting changes to those corrective releases.
>
Is this above process documented and accessbile from the GDB website somewhere?
IMHO it is something which should be dead easy to find - see for
example what we've done for mesa.

Thanks for the instructions Joel, will get back to this later in the week.
-Emil

[1] https://www.google.com/search?q=mesa+stable+patch+backport