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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.