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. p. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
