Re: Backport 037e8112b97 for the 10.x branch

[Joel Brobecker <brobecke@adacore.com>]

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