gcc: Fix strange C++ repo issues

gcc: Fix strange C++ repo issues

[Richard Purdie]

See the patch header for a better description of the c++ -frepo
issue this patch fixes.

[YOCTO #5133]

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/recipes-devtools/gcc/gcc-4.8.inc b/meta/recipes-devtools/gcc/gcc-4.8.inc
index 4af98f8..8d50bf7 100644
--- a/meta/recipes-devtools/gcc/gcc-4.8.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.8.inc
@@ -76,6 +76,7 @@ SRC_URI = "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2 \
 	   file://0044-gengtypes.patch \
 	   file://0045-gcc-4.8-PR57717-PowerPC-E500v2.patch \
 	   file://0046-libatomic-deptracking.patch \
+	   file://0047-repomembug.patch \
 	  "
 SRC_URI[md5sum] = "3b2386c114cd74185aa3754b58a79304"
 SRC_URI[sha256sum] = "545b44be3ad9f2c4e90e6880f5c9d4f0a8f0e5f67e1ffb0d45da9fa01bb05813"
diff --git a/meta/recipes-devtools/gcc/gcc-4.8/0047-repomembug.patch b/meta/recipes-devtools/gcc/gcc-4.8/0047-repomembug.patch
new file mode 100644
index 0000000..ea253f4
--- /dev/null
+++ 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
+===================================================================
+--- gcc-4.8.1.orig/gcc/toplev.c	2013-03-28 08:29:51.000000000 +0000
++++ gcc-4.8.1/gcc/toplev.c	2013-10-09 20:27:17.089228023 +0000
+@@ -551,11 +551,11 @@
+   if (flag_syntax_only || flag_wpa)
+     return;
+ 
+-  ggc_protect_identifiers = false;
+-
+   /* This must also call finalize_compilation_unit.  */
+   lang_hooks.decls.final_write_globals ();
+ 
++  ggc_protect_identifiers = false;
++
+   if (seen_error ())
+     return;
+ 

Re: gcc: Fix strange C++ repo issues

[Khem Raj]

Looks good to me. We need to run GCC testsuites on it and also propose it upstream.

Acked-by: Khem Raj <raj.khem@gmail.com>

On Oct 9, 2013, at 3:11 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:

> See the patch header for a better description of the c++ -frepo
> issue this patch fixes.
> 
> [YOCTO #5133]
> 
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> diff --git a/meta/recipes-devtools/gcc/gcc-4.8.inc b/meta/recipes-devtools/gcc/gcc-4.8.inc
> index 4af98f8..8d50bf7 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.8.inc
> +++ b/meta/recipes-devtools/gcc/gcc-4.8.inc
> @@ -76,6 +76,7 @@ SRC_URI = "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2 \
> 	   file://0044-gengtypes.patch \
> 	   file://0045-gcc-4.8-PR57717-PowerPC-E500v2.patch \
> 	   file://0046-libatomic-deptracking.patch \
> +	   file://0047-repomembug.patch \
> 	  "
> SRC_URI[md5sum] = "3b2386c114cd74185aa3754b58a79304"
> SRC_URI[sha256sum] = "545b44be3ad9f2c4e90e6880f5c9d4f0a8f0e5f67e1ffb0d45da9fa01bb05813"
> diff --git a/meta/recipes-devtools/gcc/gcc-4.8/0047-repomembug.patch b/meta/recipes-devtools/gcc/gcc-4.8/0047-repomembug.patch
> new file mode 100644
> index 0000000..ea253f4
> --- /dev/null
> +++ 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
> +===================================================================
> +--- gcc-4.8.1.orig/gcc/toplev.c	2013-03-28 08:29:51.000000000 +0000
> ++++ gcc-4.8.1/gcc/toplev.c	2013-10-09 20:27:17.089228023 +0000
> +@@ -551,11 +551,11 @@
> +   if (flag_syntax_only || flag_wpa)
> +     return;
> + 
> +-  ggc_protect_identifiers = false;
> +-
> +   /* This must also call finalize_compilation_unit.  */
> +   lang_hooks.decls.final_write_globals ();
> + 
> ++  ggc_protect_identifiers = false;
> ++
> +   if (seen_error ())
> +     return;
> + 
> 

Re: gcc: Fix strange C++ repo issues

[Phil Blundell]

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.

Re: gcc: Fix strange C++ repo issues

[Richard Purdie]

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