Re: gcc: Fix strange C++ repo issues

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2013-10-10 at 12:00 +0100, Phil Blundell wrote:
> On Wed, 2013-10-09 at 23:11 +0100, Richard Purdie wrote:
> > +++ b/meta/recipes-devtools/gcc/gcc-4.8/0047-repomembug.patch
> > @@ -0,0 +1,46 @@
> > +When compiling a project using -frepo, .rpo files are written alongside
> > +the .o file, the symbols either have O or C against them. During final linking,
> > +the objects can be recompiled with some of the entries tweaked/chosen by the 
> > +tlink.c code (visible with TLINK_VERBOSE=3).
> > +
> > +My tests showed that init_repo (cp/repo.c) was correcting calling 
> > +IDENTIFIER_REPO_CHOSEN against the right identifers.
> > +
> > +By the time finish_repo() or emit_repo_p() were called, the pointer returned
> > +by get_identifier() for the symbol marked during init_repo had changed and
> > +the chosen bit was no longer set. This lead to linking bugs like:
> > +
> > +collect: relinking
> > +collect2: error: '_ZNK6sudoku5ClearINS_8SequenceEEclERS1_' was assigned to 'board.rpo', but was not defined during recompilation, or vice versa
> > +
> > +The problem is that the garbage collection is getting called before
> > +finish_repo() is called and ggc_protect_identifiers is set to false 
> > +so the identifiers are not preserved. They are recreated but the 
> > +chosen bits get wiped out.
> > +
> > +The fix is to change ggc_protect_identifiers *after* the finish_repo 
> > +calls are made.
> > +
> > +Reproduction is tricky since you need to trigger the garbage collector at
> > +just the right moment.
> > +
> > +RP 2013/10/9
> > +
> > +Index: gcc-4.8.1/gcc/toplev.c
> 
> This patch header seems to lack an Upstream-Status.

Thanks, I've already fixed that in the version in the master-next
branch, along with tweaking the explanation a little more.

Cheers,

Richard