Synchronizing Binutils and GDB releases

Synchronizing Binutils and GDB releases

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

Cheers
   Nick

Re: Synchronizing Binutils and GDB releases

[Joel Sherrill]

On 8/18/2014 10:31 AM, Nicholas Clifton wrote:
> 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.
> Cheers
>    Nick
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Synchronizing Binutils and GDB releases

[Joel Brobecker]

Hi Nick,

>   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

Re: Synchronizing Binutils and GDB releases

[Tristan Gingold]

On 18 Aug 2014, at 17:31, Nicholas Clifton <nickc@redhat.com> wrote:

> Hi Tristan, Hi Joel,
> 
>  What do you think to the idea of synchronizing GDB and BINUTILS releases ?

I understand the packager point of view and I am not against that idea.

But, I think this can make sense only if both projects are merged, with only one release manager (team), with only one team of maintainers.  Otherwise I am afraid of misunderstanding and delays during release periods.

As a fact, very few peoples are active on both projects, so I am not sure if hackers want to unify both projects.

Maybe the binutils team can try to simply 'qualify' the gdb releases: testing the prerelease and fixing regression.  That would be lighter.

Tristan.