Hi Jan, On Fri, 2020-09-25 at 11:43 +0200, Jan Kratochvil wrote: > On Fri, 25 Sep 2020 01:35:43 +0200, Mark Wielaard wrote: > > Replying since I am mentioned by name in this proposal and it seems to > > argue for removing a feature I am currently working on to make sure it > > works correctly with GCC11 if it switches to producing DWARF5 by > > default. The proposal seems based on some misunderstandings. > > The problem is you are not working on DWARF-5 features produced by LLVM so > even your planned DWZ is still not usable for LLVM-built binaries. > [...] It is also unfair to restrict LLVM due to a deficiency of DWZ. > [...] Fedora has been waiting for DWARF-5 for 3.5 years due to DWZ. > [...] From my point of view the DWZ technology makes no sense and so > I find a better fix to drop DWZ. [...] GCC also does not support most > of DWARF-5 after it is standardized for 3.5 years (only these days > you started implementing better DWARF-5 support). [...] It is easy > for primitive tools like GDB [...] I understand DWZ is not a problem > for trivial utilities, that is not the case of LLDB. [...] > I have switched to clang in 2013 and I have never looked back. You aren't really making sure to win people over if you tell others they aren't working fast enough, they aren't prioritizing your bugs, disparaging others work because they do have implemented support for newer DWARF constructs, just not in a way you would have done it, and not being willing to help out with fixing things because you aren't personally interested in the Fedora default GNU toolchain. DWZ works totally fine with llvm produced binaries, there is even a whole distro build with clang that uses DWZ (it just doesn't use DWARF5 by default). Your comments about GCC are also wrong. GCC does support and produce almost any construct DWARF-5 specifies (after all, they used to be GNU extensions before), it just doesn't use certain forms or index tables unless you are producing split-dwarf (which like debug- types also isn't enabled by default). If you want to make -fdebug-types-sections the default you really should work with the upstream GCC developers to figure out why they don't want that. Trying to override upstream defaults in Fedora without understanding why upstream decided on the current defaults isn't a good idea IMHO. I totally get that it is frustrating if you worked for a long time on a new feature to support some DWARF constructs for lldb and your aren't able to get the patches in shape to be accepted upstream. But I am happy people now know about your patches and seem to find them useful. You say it is difficult to support DWARF partial units as generated by dwz in lldb, but dwz doesn't really do anything non-standard (and GCC with LTO also generates partial units). If your complaint is that partial unit DIEs are missing some for your use case essential attributes, then we can look at adding them (note that Tom de Vries has experimented with --devel-gen-cu and --devel-uni-lang in dwz git, which might provide you with something you can use, see the dwz commit messages for some more background). I do find your statistics per package useful because they show dwz is in general effective by producing at least 20% (more) on-disk size reduction, even though there are some packages where dwz doesn't seem as effective as it could be. We definitely should investigate those issues. When I looked at the build.logs in the past it did show some issues with either the DWARF producers, rpm debugedit or dwz. Please do report bugs if they aren't known yet to the upstream projects. But I don't really understand why you then focus on the zstd compressed rpms (even if even those favor dwz). That simply shows that zstd compression seems to work pretty well. But it doesn't show the on-disk (and in-memory) size reductions. Or why for the debuginfod use case you seem to do the opposite, not take into account that the http debuginfod server will compress the files before sending over the network. I don't think either of those later statistics are really relevant with respect to your proposal. Finally I am interested in your proposal to implement a different way to reduce the size of DIE trees by eliminating "unused" DIEs. It is hard to predict what effect that would have without seeing an implementation (in theory GCC with LTO would not actually generate debuginfo for unused functions). But I think that can be done separate from your proposal and combined with other size reduction techniques. Cheers, Mark _______________________________________________ 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
