search for: d59553

...ize of the binary we use -ffunction-sections so that unused code would be garbage collected. When the linker does garbage collection, a lot of abandoned debug info is left behind. Besides inflated debug info size, we ended up with overlapping address ranges and no way to say valid vs garbage ranges(D59553). To resolve these two problems, we use implementation extracted from dsymutil https://reviews.llvm.org/D74169. It adds --gc-debuginfo command line option to the linker to remove obsolete debug info. Currently, it has the following limitations: does not support DWARF5, modules, -fdebug-types-sectio...

...bility/existing functions/other compilers) 2) adopt the binutils approach to this (at least in debug_ranges - maybe in all debug sections? (doing it in other sections could break ) 3) Revisit the discussion about using an even more 'blessed' value, like int max-1? ( https://reviews.llvm.org/D59553 ) (I don't have links to all the recent threads about this discussion - I think D59553 might've spawned a separate broader discussion/non-review - oh, Alexey wrote a good summary with links to other discussions here: http://lists.llvm.org/pipermail/llvm-dev/2019-September/135068.html ) Th...

...; > 2) adopt the binutils approach to this (at least in debug_ranges - maybe > in all > > debug sections? (doing it in other sections could break ) > > 3) Revisit the discussion about using an even more 'blessed' value, > > like int max-1? ( https://reviews.llvm.org/D59553 ) > > > (I don't have links to all the recent threads about this discussion - I > think D59553 > > might've spawned a separate broader discussion/non-review - oh, Alexey > wrote a > > good summary with links to other discussions here: > > http://lists.llvm...

...ions/other compilers) > 2) adopt the binutils approach to this (at least in debug_ranges - maybe in all > debug sections? (doing it in other sections could break ) > 3) Revisit the discussion about using an even more 'blessed' value, > like int max-1? ( https://reviews.llvm.org/D59553<https://urldefense.com/v3/__https:/reviews.llvm.org/D59553__;!!JmoZiZGBv3RvKRSx!r2Jqc2yEgxrb2QcQEocDHJBizj0KUKE70_57b4_rsj1TN0qB8NpBvVKtY63HSqgMOg$> ) > (I don't have links to all the recent threads about this discussion - I think D59553 > might've spawned a separate broader d...

...form which uses 0 as start of .text section. - custom toolset which does not support all features yet(f.e. split dwarf). - tolerant of the link-time increase. - need a useful way to share debug builds. For the first point: we have a problem "Overlapping address ranges starting from 0"(D59553). We use custom solution, but the general solution like D74169 would be better here. For the second point: split dwarf could be a good alternative to have debug info with minimal size. Still, it has drawbacks (not supported by tools currently, does not solve the "Overlapping address ranges&qu...

...ach to this (at least in debug_ranges - maybe >> in all >> >> > debug sections? (doing it in other sections could break ) >> > 3) Revisit the discussion about using an even more 'blessed' value, >> >> > like int max-1? ( https://reviews.llvm.org/D59553 >> <https://urldefense.com/v3/__https:/reviews.llvm.org/D59553__;!!JmoZiZGBv3RvKRSx!r2Jqc2yEgxrb2QcQEocDHJBizj0KUKE70_57b4_rsj1TN0qB8NpBvVKtY63HSqgMOg$> >> ) >> >> > (I don't have links to all the recent threads about this discussion - I >> think D59553...

...fundamental/non-user-defined types into the type unit). (& it's a non-starter for Split DWARF anyway) > James Henderson might have > the actual results stashed somewhere. > > That approach *might* still be faster than post-processing a unified > section, which IIUC is what D59553 does. > > > > > So, this trick can't work without refining the --gc-sections rules > > further. > > If I understand the objection, yeah, we can't have .debug_* sections > being gc roots. I'm not sure I follow, here - "this trick" being "spli...

...> James Henderson might have > >> >> > > the actual results stashed somewhere. > >> >> > > > >> >> > > That approach *might* still be faster than post-processing a unified > >> >> > > section, which IIUC is what D59553 does. > >> >> > > > >> >> > > > > >> >> > > > So, this trick can't work without refining the --gc-sections rules > >> >> > > > further. > >> >> > > > >> >> > >...

...amp; it's a non-starter for Split DWARF anyway) > > > > > James Henderson might have > > > the actual results stashed somewhere. > > > > > > That approach *might* still be faster than post-processing a unified > > > section, which IIUC is what D59553 does. > > > > > > > > > > > So, this trick can't work without refining the --gc-sections rules > > > > further. > > > > > > If I understand the objection, yeah, we can't have .debug_* sections > > > being gc roots. >...

...l/llvm-dev/2017-December/119470.html 4. [llvm-dev] [DWARF] De-segregating type units and compile units     http://lists.llvm.org/pipermail/llvm-dev/2018-July/124819.html 5. [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if    --gc-sections used     https://reviews.llvm.org/D59553 6. Discard debuginfo for object files empty after GC     https://reviews.llvm.org/D54747 7. [ELF] Add --strip-debug-non-line option     https://reviews.llvm.org/D46628 8. Monolithic input section handling         https://groups.google.com/forum/#!msg/generic-abi/A-1rbP8hFCA/EDA7Sf3KBwAJ 9. Usin...

...t; >> > > >> > > James Henderson might have > >> > > the actual results stashed somewhere. > >> > > > >> > > That approach *might* still be faster than post-processing a unified > >> > > section, which IIUC is what D59553 does. > >> > > > >> > > > > >> > > > So, this trick can't work without refining the --gc-sections rules > >> > > > further. > >> > > > >> > > If I understand the objection, yeah, we can't have...

...ter than the two files with a bigger size. clang compiled with -gsplitdwarf takes 0.9G for executable and 0.9G for .dwp. clang compiled with -gc-debuginfo takes only 0.76G for single executable. >>For the first point: we have a problem "Overlapping address ranges starting from 0"(D59553). >>We use custom solution, but the general solution like D74169 would be better here. > If CU ranges are the only ones that need fixing, then I think the above solution might be as > good/better - if more than CU ranges need fixing, then I think we might want to start talking about &g...

...did not measure the value of size reduction for line table, though I think that it would be a small value. The more important thing is a correctness issue. Line table could contain information for overlapping address ranges. There is another attempt to fix that issue - https://reviews.llvm.org/D59553. > > We evaluated the approach on LLVM and Clang codebases. The results > obtained are summarized in the tables below: > > > Memory usage statistics (& confidence intervals for the build time) > would probably be especially useful for comparing these tradeoffs. &...

...with -gsplitdwarf takes 0.9G for executable and 0.9G for > .dwp. > > clang compiled with -gc-debuginfo takes only 0.76G for single executable. > > > > > > > > >>For the first point: we have a problem "Overlapping address ranges > starting from 0"(D59553). > > > > >>We use custom solution, but the general solution like D74169 would be > better here. > > > > > > > If CU ranges are the only ones that need fixing, then I think the > above solution might be as > > > good/better - if more than CU ran...

...>> .dwp. > >> > clang compiled with -gc-debuginfo takes only 0.76G for single executable. > >> > > >> > > >> > > >> > >>For the first point: we have a problem "Overlapping address ranges > >> starting from 0"(D59553). > >> > > >> > >>We use custom solution, but the general solution like D74169 would be > >> better here. > >> > > >> > > >> > > If CU ranges are the only ones that need fixing, then I think the > >> above soluti...

...gger size. > > clang compiled with -gsplitdwarf takes 0.9G for executable and 0.9G for .dwp. > clang compiled with -gc-debuginfo takes only 0.76G for single executable. > > > > >>For the first point: we have a problem "Overlapping address ranges starting from 0"(D59553). > > >>We use custom solution, but the general solution like D74169 would be better here. > > > > If CU ranges are the only ones that need fixing, then I think the above solution might be as > > good/better - if more than CU ranges need fixing, then I think we might w...

...g compiled with -gsplitdwarf takes 0.9G for executable and 0.9G for .dwp. > > clang compiled with -gc-debuginfo takes only 0.76G for single executable. > > > > > > > > >>For the first point: we have a problem "Overlapping address ranges starting from 0"(D59553). > > > > >>We use custom solution, but the general solution like D74169 would be better here. > > > > > > > If CU ranges are the only ones that need fixing, then I think the above solution might be as > > > good/better - if more than CU ranges need f...

...g compiled with -gsplitdwarf takes 0.9G for executable and 0.9G for .dwp. > > clang compiled with -gc-debuginfo takes only 0.76G for single executable. > > > > > > > > >>For the first point: we have a problem "Overlapping address ranges starting from 0"(D59553). > > > > >>We use custom solution, but the general solution like D74169 would be better here. > > > > > > > If CU ranges are the only ones that need fixing, then I think the above solution might be as > > > good/better - if more than CU ranges need f...

...arf takes 0.9G for executable and 0.9G for .dwp. > > > clang compiled with -gc-debuginfo takes only 0.76G for single executable. > > > > > > > > > > > > >>For the first point: we have a problem "Overlapping address ranges starting from 0"(D59553). > > > > > > >>We use custom solution, but the general solution like D74169 would be better here. > > > > > > > > > > If CU ranges are the only ones that need fixing, then I think the above solution might be as > > > > good/better -...

...able and 0.9G for .dwp. > > > > clang compiled with -gc-debuginfo takes only 0.76G for single executable. > > > > > > > > > > > > > > > > >>For the first point: we have a problem "Overlapping address ranges starting from 0"(D59553). > > > > > > > > >>We use custom solution, but the general solution like D74169 would be better here. > > > > > > > > > > > > > If CU ranges are the only ones that need fixing, then I think the above solution might be as > &gt...