Re: [PATCH] Updated LTO early debug patch

[Richard Biener <rguenther@suse.de>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 8360 bytes --]

On Mon, 31 Aug 2015, Markus Trippelsdorf wrote:

> On 2015.08.31 at 16:44 +0200, Richard Biener wrote:
> > 
> > So the state below now will pass LTO bootstrap (fingers crossing,
> > stage3 running) as well as regular bootstrap.  Iff I didn't break
> > sth in the last minute.  You need up-to-date trunk (watch out,
> > fortran seems to be broken) to pull the fixes for trunk LTO bootstrap.
> 
> Gold doesn't work at all (internal error in read_script_file, at script.cc:1608).
> 
> Even simple programs don't link anymore:
> 
> trippels@gcc2-power8 ~ % echo "int main () {}" | g++ -x c++ - -flto
> /home/trippels/bin/ld: /home/trippels/tmp/ccPhF9Ar.o: plugin needed to handle lto object
> /home/trippels/bin/ld: /home/trippels/tmp/ccjOv4bXdebugobj: plugin needed to handle lto object

Ah, I didn't notice that because I failed to pass -fuse-ld=gold to the
linker command doing the incremental debug link (and my default linker
is GNU ld).  With that fixed I can reproduce the error.

The gold ICE is new though, no idea what triggers it this time :/
Maybe it doesn't like INPUT()s in the script.  Ok - when feeding the
inputs as regular arguments it "works" up to the point that re-invokes
the plugin recursively on the objects (despite -fno-use-linker-plugin...),
eventually failing with a too long command-line:

17625 execve("./collect2", ["./collect2", "--eh-frame-hdr", "-m", 
"elf_x86_64", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", 
"-fuse-ld=gold", "-o", "/tmp/cctrgtNXdebugobj", "-r", "-L.", 
"-L/lib/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64", 
"-L/usr/lib/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64", 
"-L/lib/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64", 
....
, "-L/lib/../lib64/../lib64", "-L/usr/lib/../lib64/../lib64", 
"-L/lib/../lib64/../lib64", ...], [/* 96 vars */] <unfinished ...>

The original gold invocation is:

17546 execve("./xgcc", ["./xgcc", "-B", ".", "-fuse-ld=gold", 
"-fno-use-linker-plugin", "-o", "/tmp/ccAB4HkPdebugobj", "-r", 
"-nostdlib", "-Wl,--debug=script", "-Wl,--whole-archive", "-Wl,-T", 
"/tmp/ccCUUlgyscript", "/tmp/ccqOITb3.o", "/tmp/cc2UtXYj.o"], [/* 96 vars 
*/] <unfinished ...>
 ... 17548 
execve("/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../bin/ld.gold", 
["/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../bin/ld.gold", 
"--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", 
"/lib64/ld-linux-x86-64.so.2", "-fuse-ld=gold", "-o", 
"/tmp/ccAB4HkPdebugobj", "-r", "-L.", "-L/lib/../lib64/../lib64", 
"-L/usr/lib/../lib64/../lib64", "-L/lib/../lib64", "-L/usr/lib/../lib64", 
"-L/lib/../lib64", "-L/usr/lib/../lib64", "-L.", "-L/lib/../lib64", 
"-L/usr/lib/../lib64", "--debug=script", "--whole-archive", "-T", 
"/tmp/ccCUUlgyscript", "/tmp/ccqOITb3.o", "/tmp/cc2UtXYj.o"], [/* 96 vars 
*/]) = 0

so not sure how it figures to use (and which?) LTO plugin.  Possibly
by auto-loading?  I can't find a '-no-plugin' option or sth similar.
Oh, and with GNU ld the behavior is the same, so using actual arguments
to the link seems to be a no-go unless that can be fixed somehow.

Hmm, and somehow collect-ld doesn't handle -fuse-ld=... in response
files:

[pid 19703] execve("./xgcc", ["./xgcc", "@/tmp/cclYNnH0"], [/* 96 vars */] 
<unfinished ...>
...
[pid 19704] execve("./collect2", ["./collect2", "--eh-frame-hdr", "-m", 
"elf_x86_64", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", 
"-fuse-ld=gold", "-o", "/tmp/ccvlTEtRdebugobj", "-r", "-L.", 
"-L/lib/../lib64/../lib64", "-L/usr/lib/../lib64/../lib64", 
"-L/lib/../lib64", "-L/usr/lib/../lib64", "-L/lib/../lib64", ...], [/* 96 
vars */] <unfinished ...>
...
[pid 19705] execve("./collect-ld", ["./collect-ld", "@/tmp/ccjliwz5"], [/* 
96 vars */] <unfinished ...>
...
[pid 19705] 
execve("/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld", 
["/usr/lib64/gcc/x86_64-suse-linux"..., "@/tmp/ccjliwz5"], [/* 96 vars 
*/]) = 0

that's when passing true to fork_execute.

So I don't have a workaround for GOLD and early LTO debug (apart from
eventually forcing a -fuse-ld=bfd for the incremental link).

As said, the final version will require support from the linkers
but it seems https://sourceware.org/bugzilla/show_bug.cgi?id=18837
is stalled.

> And it breaks quickly during Firefox build, e.g.:
> 
> trippels@gcc2-power8 angle % cat glslang_lex.ii
> struct A;
> template <typename = int> class B {
>   typedef A value_type;
>   void m_fn1(const value_type &);
> };
> struct A {
>   int staticUse;
> B<> fields;
> };
> 
> trippels@gcc2-power8 angle % g++ -g -c glslang_lex.ii
> glslang_lex.ii: In instantiation of ‘class B<>’:
> glslang_lex.ii:8:5:   required from here
> glslang_lex.ii:2:33: error: TYPE_CANONICAL is not compatible

Hum, but that looks more like an issue for Honzas type verifier (which
already has quite a few bugs ...).  dwarf2out certainly doesn't
modify types.

Anyway, thanks for trying ;)

Richard.

>  template <typename = int> class B {
>                                  ^
>  <record_type 0x3fffa9d4cb70 A readonly type_5 VOID
>     align 8 symtab 0 alias set -1 canonical type 0x3fffa9d4cb70 context <translation_unit_decl 0x3fffb2770078 D.1>
>     full-name "const struct A"
>     n_parents=0 use_template=0 interface-unknown reference_to_this <reference_type 0x3fffa9d4ccc0>>
>  <record_type 0x3fffa9d4d3f8 value_type readonly used type_5 VOID
>     align 8 symtab -1446640944 alias set -1 canonical type 0x3fffa9d4cb70
>     fields <field_decl 0x3fffa9c44c00 staticUse
>         type <integer_type 0x3fffa9b90690 int public type_6 SI
>             size <integer_cst 0x3fffa9b416b0 constant 32>
>             unit size <integer_cst 0x3fffa9b416c8 constant 4>
>             align 32 symtab 0 alias set -1 canonical type 0x3fffa9b90690 precision 32 min <integer_cst 0x3fffa9b41668 -2147483648> max <integer_cst 0x3fffa9b41680 2147483647>
>             pointer_to_this <pointer_type 0x3fffa9b917a0>>
>         decl_3 VOID file glslang_lex.ii line 7 col 7
>         align 1 offset_align 1 context <record_type 0x3fffa9d4c780 A>
>         chain <type_decl 0x3fffa9c44b68 A type <record_type 0x3fffa9d4d158 A>
>             nonlocal decl_4 VOID file glslang_lex.ii line 6 col 10
>             align 1 context <record_type 0x3fffa9d4c780 A> result <record_type 0x3fffa9d4c780 A>
>            >> context <translation_unit_decl 0x3fffb2770078 D.1>
>     full-name "const value_type"
>     n_parents=0 use_template=0 interface-unknown reference_to_this <reference_type 0x3fffa9d4d4a0>>
> glslang_lex.ii:2:33: internal compiler error: verify_type failed
> 0x10d74f97 verify_type(tree_node const*)
>         ../../gcc/gcc/tree.c:13583
> 0x10633373 gen_type_die_with_usage
>         ../../gcc/gcc/dwarf2out.c:20824
> 0x10633c17 gen_type_die_with_usage
>         ../../gcc/gcc/dwarf2out.c:20922
> 0x10635347 gen_type_die
>         ../../gcc/gcc/dwarf2out.c:21018
> 0x10635a43 gen_formal_types_die
>         ../../gcc/gcc/dwarf2out.c:18564
> 0x10636843 gen_subprogram_die
>         ../../gcc/gcc/dwarf2out.c:19341
> 0x10638067 gen_decl_die
>         ../../gcc/gcc/dwarf2out.c:21668
> 0x1064fdd7 gen_member_die
>         ../../gcc/gcc/dwarf2out.c:20516
> 0x1064fdd7 gen_struct_or_union_type_die
>         ../../gcc/gcc/dwarf2out.c:20600
> 0x1064fdd7 gen_tagged_type_die
>         ../../gcc/gcc/dwarf2out.c:20801
> 0x10633caf gen_type_die_with_usage
>         ../../gcc/gcc/dwarf2out.c:20963
> 0x10635347 gen_type_die
>         ../../gcc/gcc/dwarf2out.c:21018
> 0x10638443 gen_decl_die
>         ../../gcc/gcc/dwarf2out.c:21691
> 0x106392ef dwarf2out_decl
>         ../../gcc/gcc/dwarf2out.c:22161
> 0x10652bb7 dwarf2out_type_decl
>         ../../gcc/gcc/dwarf2out.c:21871
> 0x1093143f rest_of_type_compilation(tree_node*, int)
>         ../../gcc/gcc/passes.c:347
> 0x1028284b finish_struct_1(tree_node*)
>         ../../gcc/gcc/cp/class.c:6747
> 0x1023f92f instantiate_class_template_1
>         ../../gcc/gcc/cp/pt.c:10189
> 0x1023f92f instantiate_class_template(tree_node*)
>         ../../gcc/gcc/cp/pt.c:10229
> 0x10316453 complete_type(tree_node*)
>         ../../gcc/gcc/cp/typeck.c:138
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <http://gcc.gnu.org/bugs.html> for instructions.