[Bug lto/86517] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517 --- Comment #10 from Jan Hubicka --- Author: hubicka Date: Sun Jan 6 15:51:45 2019 New Revision: 267610 URL: https://gcc.gnu.org/viewcvs?rev=267610=gcc=rev Log: PR lto/86517 PR lto/88185 * lto-opts.c (lto_write_options): Always stream PIC/PIE mode. * lto-wrapper.c (merge_and_complain): Fix merging of PIC/PIE. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/lto-opts.c branches/gcc-8-branch/gcc/lto-wrapper.c
[Bug lto/86517] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517 Martin Liška changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Liška --- Closing as we're probably not planning to backport.
[Bug lto/86517] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517 --- Comment #8 from Jan Hubicka --- Author: hubicka Date: Thu Aug 30 15:50:39 2018 New Revision: 263988 URL: https://gcc.gnu.org/viewcvs?rev=263988=gcc=rev Log: PR lto/86517 * lto-opts.c (lto_write_options): Always stream PIC/PIE mode. * lto-wrapper.c (merge_and_complain): Fix merging of PIC/PIE. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-opts.c trunk/gcc/lto-wrapper.c
[Bug lto/86517] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517
--- Comment #7 from Jan Hubicka ---
Hi,
I am attaching patch I am testing and also table generated by a script that
walks through individual combinations of options. The combination rules are as
follows.
I tried to take into account that targets may default to some form of PIC or
PIE. That is why, for example combining -fpic and empty options results in
empty options and no no-pic.
Note that in addition to lto-wrapper option merging we now have logic that
disables PIC/PIE when final binary is built based on lto-plugion output (it
knows if it builds binary, relocatable binary, library or incrementally links).
Still we rely on the merging to choose particular form of PIC/PIE and we need
it right in incremental link where linker does not help us.
-fpic +-fpic => -fpic
-fpic +-fPIC => -fpic
-fpic +-fpie => -fpie
-fpic +-fPIE => -fpie
-fpic + -fno-pic => -fno-pic
-fpic + -fno-pie =>
-fpic + =>
-fPIC +-fpic => -fpic
-fPIC +-fPIC => -fPIC
-fPIC +-fpie => -fpie
-fPIC +-fPIE => -fPIE
-fPIC + -fno-pic => -fno-pic
-fPIC + -fno-pie =>
-fPIC + =>
-fpie +-fpic => -fpie
-fpie +-fPIC => -fpie
-fpie +-fpie => -fpie
-fpie +-fPIE => -fpie
-fpie + -fno-pic =>
-fpie + -fno-pie =>
-fpie + =>
-fPIE +-fpic => -fpie
-fPIE +-fPIC => -fPIE
-fPIE +-fpie => -fpie
-fPIE +-fPIE => -fPIE
-fPIE + -fno-pic =>
-fPIE + -fno-pie =>
-fPIE + =>
-fno-pic +-fpic => -fno-pic
-fno-pic +-fPIC => -fno-pic
-fno-pic +-fpie => -fno-pic
-fno-pic +-fPIE => -fno-pic
-fno-pic + -fno-pic => -fno-pic
-fno-pic + -fno-pie => -fno-pic
-fno-pic + => -fno-pic
-fno-pie +-fpic => -fno-pie
-fno-pie +-fPIC => -fno-pie
-fno-pie +-fpie => -fno-pie
-fno-pie +-fPIE => -fno-pie
-fno-pie + -fno-pic => -fno-pie
-fno-pie + -fno-pie => -fno-pie
-fno-pie + => -fno-pie
-fpic + =>
-fPIC + =>
-fpie + =>
-fPIE + =>
-fno-pic + =>
-fno-pie + =>
+ =>
Index: lto-wrapper.c
===
--- lto-wrapper.c (revision 262682)
+++ lto-wrapper.c (working copy)
@@ -408,6 +408,11 @@ merge_and_complain (struct cl_decoded_op
It is a common mistake to mix few -fPIC compiled objects into otherwise
non-PIC code. We do not want to build everything with PIC then.
+ Similarly we merge PIE options, however in addition we keep
+ -fPIC + -fPIE = -fPIE
+ -fpic + -fPIE = -fpie
+ -fPIC/-fpic + -fpie = -fpie
+
It would be good to warn on mismatches, but it is bit hard to do as
we do not know what nothing translates to. */
@@ -415,11 +420,34 @@ merge_and_complain (struct cl_decoded_op
if ((*decoded_options)[j].opt_index == OPT_fPIC
|| (*decoded_options)[j].opt_index == OPT_fpic)
{
- if (!pic_option
- || (pic_option->value > 0) != ((*decoded_options)[j].value > 0))
- remove_option (decoded_options, j, decoded_options_count);
- else if (pic_option->opt_index == OPT_fPIC
-&& (*decoded_options)[j].opt_index == OPT_fpic)
+ /* -fno-pic in one unit implies -fno-pic everywhere. */
+ if ((*decoded_options)[j].value == 0)
+ j++;
+ /* If we have no pic option or merge in -fno-pic, we still may turn
+ existing pic/PIC mode into pie/PIE if -fpie/-fPIE is present. */
+ else if ((pic_option && pic_option->value == 0)
+|| !pic_option)
+ {
+ if (pie_option && pie_option->value > 0)
+ {
+ bool big = (*decoded_options)[j].opt_index == OPT_fPIC
+ && pie_option->opt_index == OPT_fPIE;
+ (*decoded_options)[j].opt_index = big ? OPT_fPIE : OPT_fpie;
+ (*decoded_options)[j].canonical_option[0] = big ? "-fPIE" :
"-fpie";
+ j++;
+ }
+ else if (pic_option)
+ {
+ (*decoded_options)[j] = *pic_option;
+ j++;
+ }
+ /* We do not know if target defaults to pic or not, so just remove
+ option if it is missing in one unit but enabled in other. */
+ else
+ remove_option (decoded_options, j, decoded_options_count);
+ }
+ else if (pic_option->opt_index == OPT_fpic
+&& (*decoded_options)[j].opt_index == OPT_fPIC)
{
(*decoded_options)[j] = *pic_option;
j++;
@@ -430,11 +458,37 @@ merge_and_complain (struct cl_decoded_op
else if ((*decoded_options)[j].opt_index == OPT_fPIE
|| (*decoded_options)[j].opt_index == OPT_fpie)
{
- if
[Bug lto/86517] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517
--- Comment #6 from Jan Hubicka ---
The problem is logic in lto-wrapper (which is mine)
/* Merge PIC options:
-fPIC + -fpic = -fpic
-fPIC + -fno-pic = -fno-pic
-fpic/-fPIC + nothin = nothing.
It is a common mistake to mix few -fPIC compiled objects into otherwise
non-PIC code. We do not want to build everything with PIC then.
It would be good to warn on mismatches, but it is bit hard to do as
we do not know what nothing translates to. */
for (unsigned int j = 0; j < *decoded_options_count;)
if ((*decoded_options)[j].opt_index == OPT_fPIC
|| (*decoded_options)[j].opt_index == OPT_fpic)
{
if (!pic_option
|| (pic_option->value > 0) != ((*decoded_options)[j].value > 0))
remove_option (decoded_options, j, decoded_options_count);
else if (pic_option->opt_index == OPT_fPIC
&& (*decoded_options)[j].opt_index == OPT_fpic)
{
(*decoded_options)[j] = *pic_option;
j++;
}
else
j++;
}
else if ((*decoded_options)[j].opt_index == OPT_fPIE
|| (*decoded_options)[j].opt_index == OPT_fpie)
{
if (!pie_option
|| pie_option->value != (*decoded_options)[j].value)
remove_option (decoded_options, j, decoded_options_count);
else if (pie_option->opt_index == OPT_fPIE
&& (*decoded_options)[j].opt_index == OPT_fpie)
{
(*decoded_options)[j] = *pie_option;
j++;
}
else
j++;
}
PIC merging is OK, but PIE merging should not remove PIE if PIC is provided in
other units.
I am looking into fix.
Honza
[Bug lto/86517] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2018-07-16 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #5 from Martin Liška --- Reopening as I provided full reproducer.
[Bug lto/86517] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517 --- Comment #4 from Martin Liška --- Created attachment 44397 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44397=edit Full reproducer As mentioned in my first commit, -shared was only used in order to reduce the test-case. I'm attaching full version that show issue with: $ rm x.a ; gcc -fPIC -c -O2 lib*.i -flto && ar rv x.a lib*.o && gcc -rdynamic -fPIE [1-9].i -c -O2 -flto && gcc -pie [1-9].o -rdynamic x.a -pthread -ldl -lxml2 -flto That works: $ rm x.a ; gcc -fPIC -c -O2 lib*.i && ar rv x.a lib*.o && gcc -rdynamic -fPIE [1-9].i -c -O2 && gcc -pie [1-9].o -rdynamic x.a -pthread -ldl -lxml2
[Bug lto/86517] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517 --- Comment #3 from H.J. Lu --- (In reply to Jan Hubicka from comment #2) > I think the problem here is that you can compile PIE and PIC object into pie > binary He used gcc -pie -O2 -pthread -ldl -lxml2 1.o 2.o x.a -rdynamic -flto=9 -shared ^ -shared overrides -pie. He was building a shared object, not a PIE.
[Bug lto/86517] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517 --- Comment #2 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517 > > H.J. Lu changed: > >What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > CC||hjl.tools at gmail dot com > Resolution|--- |INVALID > > --- Comment #1 from H.J. Lu --- > I(In reply to Martin Liška from comment #0) > > > > > $ gcc -flto -c -fPIE -O2 1.i 2.i && gcc -fPIC -c -O2 lib.i -flto && ar rv > > x.a lib.o && gcc -pie -O2 -pthread -ldl -lxml2 1.o 2.o x.a -rdynamic -flto=9 > > -shared > > r - lib.o > > I don't believe you can build a shared object with -fPIE and linker tells > you to recompile with -fPIC. I think the problem here is that you can compile PIE and PIC object into pie binary at least on x86-64, but the way we merge options in lto-wrapper, we disable both PIE and PIC at LTO linktime. I think we ought to consider PIE as lower variant of PIC and resolve such funny combination as -fPIE. Honza
[Bug lto/86517] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hjl.tools at gmail dot com Resolution|--- |INVALID --- Comment #1 from H.J. Lu --- I(In reply to Martin Liška from comment #0) > > $ gcc -flto -c -fPIE -O2 1.i 2.i && gcc -fPIC -c -O2 lib.i -flto && ar rv > x.a lib.o && gcc -pie -O2 -pthread -ldl -lxml2 1.o 2.o x.a -rdynamic -flto=9 > -shared > r - lib.o I don't believe you can build a shared object with -fPIE and linker tells you to recompile with -fPIC.
