https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86654
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 24 Jul 2018, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86654 > > --- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> --- > With the dwarf2out.c file patches, now the library builds. But it took my ~30 > minutes of linking, seeing perf top: > > 36.96% lto1 [.] lookup_external_ref > 18.60% lto1 [.] hash_table<external_ref_hasher, > xcallocator>::find_empty_slot_for_expand > 4.68% as [.] hash_lookup.isra.0 > 1.92% as [.] resolve_symbol_value > 0.74% lto1 [.] mark_used_flags > 0.72% as [.] relax_segment So you applied the first patch as well? That was for debugging. And it didn't fire? That's very good ;) > and debug info of the shared library looks huge: > > bloaty ./obj-x86_64-pc-linux-gnu/toolkit/library/libxul.so > VM SIZE FILE SIZE > -------------- -------------- > 0.0% 0 .debug_info 937Mi 52.7% > 0.0% 0 .debug_loc 339Mi 19.1% > 0.0% 0 .debug_str 159Mi 9.0% > 0.0% 0 .debug_ranges 110Mi 6.2% > 0.0% 0 .debug_line 69.0Mi 3.9% > 68.3% 65.3Mi .text 65.3Mi 3.7% > 0.0% 0 .strtab 33.1Mi 1.9% > 0.0% 0 .symtab 24.4Mi 1.4% > 0.0% 0 .debug_abbrev 9.99Mi 0.6% > 8.3% 7.91Mi .rela.dyn 7.91Mi 0.4% > 8.0% 7.67Mi .rodata 7.67Mi 0.4% > 6.2% 5.89Mi .eh_frame 5.89Mi 0.3% > 4.1% 3.90Mi .data.rel.ro 3.90Mi 0.2% > 1.7% 1.59Mi .dynstr 1.59Mi 0.1% > 1.4% 1.35Mi .eh_frame_hdr 1.35Mi 0.1% > 1.0% 990Ki [Other] 1003Ki 0.1% > 0.6% 616Ki .bss 0 0.0% > 0.4% 398Ki .dynsym 398Ki 0.0% > 0.0% 0 .debug_pubtypes 349Ki 0.0% > 0.0% 0 .debug_pubnames 285Ki 0.0% > 0.0% 23 [None] 0 0.0% > 100.0% 95.6Mi TOTAL 1.74Gi 100.0% Not so bad I think. How's its size without LTO? 0.0% 0 .debug_info 67.1Mi 52.8% 58.2% 22.1Mi .text 22.1Mi 17.4% but yes, PR83941 could be a reason for some bloat. You could try "counting" the number of DIEs that just contain a single DW_AT_abstract_origin attribute and no children.
