[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2010-11-10 18:01:19 UTC --- I have verified that http://sourceware.org/ml/binutils/2010-11/msg00170.html fixes the problem.
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 --- Comment #12 from Dave Korn davek at gcc dot gnu.org 2010-11-10 22:52:55 UTC --- (In reply to comment #11) I have verified that http://sourceware.org/ml/binutils/2010-11/msg00170.html fixes the problem. Thanks HJ. I can't self-approve patches to that code but I'll check it in just as soon as I can, on the branch and head. (I imagine you want to get on with a linux-binutils release.)
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2010-11-11 01:46:40 UTC --- (In reply to comment #12) (In reply to comment #11) I have verified that http://sourceware.org/ml/binutils/2010-11/msg00170.html fixes the problem. Thanks HJ. I can't self-approve patches to that code but I'll check it in just as soon as I can, on the branch and head. (I imagine you want to get on with a linux-binutils release.) I have included your patch in the next Linux binutils. Thanks.
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Keywords||patch URL||http://sourceware.org/ml/bi ||nutils/2010-11/msg00170.htm ||l --- Comment #10 from Dave Korn davek at gcc dot gnu.org 2010-11-09 19:32:13 UTC --- Binutils with the posted patch passes LTO-bootstrap using LD as the linker plugin and resolves the failing tests.
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 --- Comment #8 from Dave Korn davek at gcc dot gnu.org 2010-11-08 04:52:12 UTC --- The generated source file selfassign.so.ltrans0.s (and hence also the object file selfassign.so.ltrans0.ltrans.o) file which gets created when lto-plugin invokes lto1 on the original input selfassign.o file has no contents. This appears to be because plugin_init in selfassign.c isn't marked with __attribute__((externally_visible)), and the resolution file marks it as PREVAILING_DEF_IRONLY. WPA then concludes that everything can be made static, nothing is referenced, and discards the lot. The consequence of this is that the object file that the pluging then adds back into the link has no contents, so it doesn't override the symbol definitions supplied from the IR when it first claimed the input selfassign.o file. It works with GOLD because GOLD thinks the plugin's external symbols are PREVAILING_DEF, not PREVAILING_DEF_IRONLY. This is the resolution file that the lto-plugin writes based on what LD tells it at all_symbols_read time: 1 selfassign.o 27 5072 e2eb6ce9 PREVAILING_DEF_IRONLY plugin_init 5105 e2eb6ce9 UNDEF tree_check_failed 5114 e2eb6ce9 UNDEF tree_class_check_failed 5148 e2eb6ce9 UNDEF fancy_abort 5155 e2eb6ce9 UNDEF gimple_check_failed 5165 e2eb6ce9 UNDEF gimple_assign_single_p 5169 e2eb6ce9 UNDEF tree_contains_struct_check_failed 5253 e2eb6ce9 UNDEF build4_stat 5262 e2eb6ce9 UNDEF tree_operand_check_failed 5271 e2eb6ce9 UNDEF fold_build2_stat_loc 5279 e2eb6ce9 UNDEF build3_stat 5287 e2eb6ce9 UNDEF warning_at 5302 e2eb6ce9 UNDEF operand_equal_p 5308 e2eb6ce9 UNDEF maybe_get_identifier 5312 e2eb6ce9 UNDEF integer_zerop 5314 e2eb6ce9 UNDEF register_callback 5324 e2eb6ce9 UNDEF warning 5351 e2eb6ce9 UNDEF plugin_default_version_check 5494 e2eb6ce9 PREVAILING_DEF_IRONLY check_operator_eq 5536 e2eb6ce9 PREVAILING_DEF_IRONLY plugin_is_GPL_compatible 5433 e2eb6ce9 UNDEF tree_code_type 5442 e2eb6ce9 UNDEF tree_code_length 5452 e2eb6ce9 UNDEF gss_for_code_ 5457 e2eb6ce9 UNDEF gimple_ops_offset_ 5471 e2eb6ce9 UNDEF tree_contains_struct 5486 e2eb6ce9 UNDEF input_location 5502 e2eb6ce9 UNDEF cfun ... and here is the one generated when the plugin is loaded into GOLD: 1 selfassign.o 27 5072 e2eb6ce9 PREVAILING_DEF plugin_init 5105 e2eb6ce9 UNDEF tree_check_failed 5114 e2eb6ce9 UNDEF tree_class_check_failed 5148 e2eb6ce9 UNDEF fancy_abort 5155 e2eb6ce9 UNDEF gimple_check_failed 5165 e2eb6ce9 UNDEF gimple_assign_single_p 5169 e2eb6ce9 UNDEF tree_contains_struct_check_failed 5253 e2eb6ce9 UNDEF build4_stat 5262 e2eb6ce9 UNDEF tree_operand_check_failed 5271 e2eb6ce9 UNDEF fold_build2_stat_loc 5279 e2eb6ce9 UNDEF build3_stat 5287 e2eb6ce9 UNDEF warning_at 5302 e2eb6ce9 UNDEF operand_equal_p 5308 e2eb6ce9 UNDEF maybe_get_identifier 5312 e2eb6ce9 UNDEF integer_zerop 5314 e2eb6ce9 UNDEF register_callback 5324 e2eb6ce9 UNDEF warning 5351 e2eb6ce9 UNDEF plugin_default_version_check 5494 e2eb6ce9 PREVAILING_DEF check_operator_eq 5536 e2eb6ce9 PREVAILING_DEF plugin_is_GPL_compatible 5433 e2eb6ce9 UNDEF tree_code_type 5442 e2eb6ce9 UNDEF tree_code_length 5452 e2eb6ce9 UNDEF gss_for_code_ 5457 e2eb6ce9 UNDEF gimple_ops_offset_ 5471 e2eb6ce9 UNDEF tree_contains_struct 5486 e2eb6ce9 UNDEF input_location 5502 e2eb6ce9 UNDEF cfun
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 --- Comment #9 from Dave Korn davek at gcc dot gnu.org 2010-11-08 06:27:25 UTC --- (In reply to comment #8) This appears to be because plugin_init in selfassign.c isn't marked with __attribute__((externally_visible)), and the resolution file marks it as PREVAILING_DEF_IRONLY. It works with GOLD because GOLD thinks the plugin's external symbols are PREVAILING_DEF, not PREVAILING_DEF_IRONLY. Thanks to Ian T, I now have an understanding of why GOLD does this: it is because if the ELF symbol visibility is STV_DEFAULT or STV_PROTECTED, GOLD assumes it may be externally referenced, perhaps dynamically at runtime, so doesn't resolve it _IRONLY. I'll need to adjust GNU LD to match this behaviour. (Can't work around it just by tagging __attribute__((externally_visible)) onto the definition of plugin_init in selfassign.c, because cc1 has been lto-bootstrapped, and all the symbols that the plugin wants to reference have been made static for the same reason - they are seen as IRONLY - so the plugin can't resolve them and dlopen'ing it fails.)
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Summary|LTO plugin test failures|LTO plugin test failures |with --with-plugin-ld=ld|with ||--with-build-config=bootstr ||ap-lto --with-plugin-ld=ld --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-11-05 17:27:27 UTC --- Removing --with-build-config=bootstrap-lto seems to fix those failures. --with-build-config=bootstrap-lto -with-plugin-ld=ld.gold works fine. It looks like plugin support in BFD linker doesn't work with GCC plugin.
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.05 17:44:25 AssignedTo|unassigned at gcc dot |davek at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Dave Korn davek at gcc dot gnu.org 2010-11-05 17:44:25 UTC --- investigating, thanks for the report
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319
--- Comment #3 from Dave Korn davek at gcc dot gnu.org 2010-11-05 22:59:04
UTC ---
When I tried running these tests in a pre-existing build tree,
plugin_default_version_check failed because the datestamps don't match up:
(gdb) p gcc_version[0]
$5 = {basever = 0x1029fe8 4.6.0, datestamp = 0x1029fee 20101103,
devphase = 0x1029ff7 experimental, revision = 0x1143f30 ,
configuration_arguments = 0xd2d2c0 /n/10/davek/gcc/gcc/configure
--prefix=/n/
10/davek/gcc --with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4
-
-with-mpc=/opt/cfarm/mpc-0.8 --with-libelf=/n/10/davek/usr --enable-bootstrap
.
..}
(gdb) p plugin_version[0]
$6 = {basever = 0x77567d29 4.6.0,
datestamp = 0x77567d2f 20101105,
devphase = 0x77567d38 experimental, revision = 0x77567e28 ,
configuration_arguments = 0x77566720 /n/10/davek/gcc/gcc/configure
--pref
ix=/n/10/davek/gcc --with-mpfr=/opt/cfarm/mpfr-2.4.1
--with-gmp=/opt/cfarm/gmp-4
.2.4 --with-mpc=/opt/cfarm/mpc-0.8 --with-libelf=/n/10/davek/usr
--enable-bootst
rap ...}
(gdb)
This will happen if $objdir/gcc/plugin-version.h or $objdir/gcc/configargs.h
has been regenerated for any reason in between building the compiler and
running the test. Can you tell if this may have happened in your case?
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2010-11-05 23:27:51 UTC --- -fwhopr=jobserver -fuse-linker-plugin -frandom-seed=1 miscompiled selfassign.so. It generated: [...@gnu-32 stage1-gcc]$ nm selfassign.so | grep plugin_init 09aa T plugin_init [...@gnu-32 stage1-gcc]$ 9aa check_operator_eq: 9aa: 90 nop 9ab: 90 nop 9ac: 90 nop 9ad: 90 nop 9ae: 90 nop 9af: 90 nop Everything seems wrong. With gold as plugin linker, I got [...@scel-amdbar2 gcc]$ nm selfassign.so | grep plugin_init 20ac T plugin_init [...@scel-amdbar2 gcc]$ 20ac plugin_init: 20ac: 41 57 push %r15 20ae: 41 56 push %r14 20b0: 41 55 push %r13 20b2: 41 54 push %r12 20b4: 55 push %rbp 20b5: 53 push %rbx 20b6: 48 83 ec 38 sub$0x38,%rsp 20ba: 48 89 f0mov%rsi,%rax 20bd: 4c 8b 2fmov(%rdi),%r13 20c0: 44 8b 67 10 mov0x10(%rdi),%r12d 20c4: 48 8b 6f 18 mov0x18(%rdi),%rbp 20c8: 48 8d 35 11 1c 00 00lea0x1c11(%rip),%rsi# 3ce0
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2010-11-05 23:30:36 UTC --- Created attachment 22300 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22300 selfassign.so generated by bfd linker
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2010-11-05 23:31:23 UTC --- Created attachment 22301 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22301 selfassign.so generated by gold
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 --- Comment #7 from Dave Korn davek at gcc dot gnu.org 2010-11-05 23:33:29 UTC --- (In reply to comment #4) Everything seems wrong. Yes, you aren't exaggerating! I am continuing to try and figure out what's going wrong.
