On Fri, 25 Sep 2020 13:56:47 +0200, Jakub Jelinek wrote: > Jan had probably problems getting his DWZ support upstreamed into LLDB It isn't completely easy, I have already upstreamed a lot of preparatory work for the DWZ patchset which is good for LLDB in general. Just before upstreaming the final DWZ-specific part I am trying to provide a better solution for Fedora as the numbers I have benchmarked do not speak for the overcomplicated DWZ solution. > and decided to spend his time instead non-constructively trying to kill DWZ. Simplifying Fedora toolchains is more constructive than supporting complicated format with no benefits. > -fdebug-types-section in GCC is pretty much unmaintained, almost nobody is > really using it, According to Richard Biener from GCC -fdebug-types-section is a normally supported GCC feature: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878#c6 > and the debug types design is quite flawed and shouldn't > have been added into DWARF. So why is Google using it for everything? I have this opinion about DWZ. > What DWZ implements is what DWARF3 and onwards have been documenting as > DWARF compression technique, before DWARF5 for the multi-file it has been > using an extension but that is now standardized in DWARF5. It is specified by the standard but without .debug_names support which is essential for effective DWARF consumers. Also not everything that got accepted into the DWARF standard is necessarily a good thing. Besides that DWZ could have better size reduction if: * it did not contain so many bugs it fails on many files * it did not give up on larger debuginfos due to running out of memory: it could implement slower alternative algorithms with on-disk temporary files > Mark is actively working on DWARF5 support for dwz right now, Mark Wielaard does not plan to support DWARF-5 features being used by LLVM. > DWZ primarily just removes redundancies, when > the DIEs are the same, and doesn't really matter what kind of DIEs it is, > while -fdebug-types-section is about types only, and does significantly > change what the debug info contains and how it can be referenced. DWZ's only possible benefit is the DWZ common file. Without DWZ common file for reasons listed above DWZ produces 1.6% bigger debuginfo than -fdebug-types-section while requiring 8x more complicated consumers. And for example for downloading of separate *.debug files DWZ is even bigger than -fdebug-types-section exactly because of the DWZ common files which are a double-edged sword. Besides that it is all about few percents of size nobody cares about. > DWZ in theory could handle what > -fdebug-types-section produces and undo the significant size overhead it > adds due to the large references (basically could undo the type units and > turn them back into normal .debug_info). Those "large references" are already considered in the numbers I provided. If one removes the "large references" together with dead DIES (address zero) one has the same size decrease as DWZ without any DWZ needed. Jan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
