From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: gcc: Fix strange C++ repo issues
Date: Wed, 09 Oct 2013 23:11:55 +0100 [thread overview]
Message-ID: <1381356715.29912.48.camel@ted> (raw)
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;
+
next reply other threads:[~2013-10-09 22:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-09 22:11 Richard Purdie [this message]
2013-10-10 6:21 ` gcc: Fix strange C++ repo issues Khem Raj
2013-10-10 11:00 ` Phil Blundell
2013-10-10 11:12 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1381356715.29912.48.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox