Discussion:
Synchronizing Binutils and GDB releases
(too old to reply)
Nicholas Clifton
2014-08-18 15:31:23 UTC
Permalink
Hi Tristan, Hi Joel,

What do you think to the idea of synchronizing GDB and BINUTILS
releases ?

The idea was raised at this year's GNU Tool's Cauldron. It would
help users who manage combined toolchain sources. Currently if they
want to create a combined tree of specific releases of the gcc, gdb and
binutils they have to choose which version of the BFD library to use.
But if they find a bug and want to check in a fix, they have to remember
that there are actually two versions of the BFD sources to patch.
Multiply this by a number of different GDB/BINUTILS release
combintations and this becomes a maintenance headache.


If we had a combined release there would be only one branch in the
git repository and things would be a lot simpler. We could even extend
this idea by arranging for the release to happen slightly before each
GCC release. Then GCC version X could could say that it works best with
GDB/BINUTILS version Y.

Cheers
Nick
Joel Sherrill
2014-08-18 15:42:19 UTC
Permalink
Post by Nicholas Clifton
Hi Tristan, Hi Joel,
What do you think to the idea of synchronizing GDB and BINUTILS
releases ?
The idea was raised at this year's GNU Tool's Cauldron. It would
help users who manage combined toolchain sources. Currently if they
want to create a combined tree of specific releases of the gcc, gdb and
binutils they have to choose which version of the BFD library to use.
But if they find a bug and want to check in a fix, they have to remember
that there are actually two versions of the BFD sources to patch.
Multiply this by a number of different GDB/BINUTILS release
combintations and this becomes a maintenance headache.
If we had a combined release there would be only one branch in the
git repository and things would be a lot simpler. We could even extend
this idea by arranging for the release to happen slightly before each
GCC release. Then GCC version X could could say that it works best with
GDB/BINUTILS version Y.
I can't speak for the entire world but I know that since the move to
git, I have
been building binutils+gdb as one unit and gcc+newilb as another. It has
simplified
my testing of the RTEMS targets and appears to shave a little time off
the builds.

OTOH we have sometimes managed to upgrade a gdb on an old
binutils/gcc/newlib.
It is usually low risk because we don't try to share the BFD library. We
have treated
gdb and binutils as separate entities. Updating binutils would force us
to rebuild
gcc+newlib. If a BFD patch were needed, we would evaluate what to do. It
might be
a patch to binutils and a gdb upgrade.

But we are a unique project in that we prefer end users to build from
source. Linux
distros would be in a different position.
Post by Nicholas Clifton
Cheers
Nick
--
Joel Sherrill, Ph.D. Director of Research & Development
***@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Joel Brobecker
2014-08-18 16:09:06 UTC
Permalink
Hi Nick,
Post by Nicholas Clifton
The idea was raised at this year's GNU Tool's Cauldron. It would
help users who manage combined toolchain sources. Currently if they
want to create a combined tree of specific releases of the gcc, gdb
and binutils they have to choose which version of the BFD library to
use. But if they find a bug and want to check in a fix, they have to
remember that there are actually two versions of the BFD sources to
patch. Multiply this by a number of different GDB/BINUTILS release
combintations and this becomes a maintenance headache.
I've been trying to think this through a little:

Binutil's schedule is roughly one release per year. GDB's schedule
is usually 2, but can depend on new features. I don't think that GDB
is thinking of changing the frequency of its releases, so unless
binutils switches to two releases a year, the two projects are not
even on the same schedule. And the release numbering is also different.

Also, finding a branchpoint for a release branch has never been easy
in the past, and having to now consider both binutils and gdb for
creating that branch is only going to make things harder either by
delaying the branching, or by creating more backports.

I think that it would be an extra burden for both projects, and
at the same time, I am not sure I am seeing how it would still
be beneficial for both binutils and GDB to be adoption these
shared release branches. Maybe it's because I don't see why using
a combined tree is making things any different?
--
Joel
Loading...