On Tue, Sep 29, 2020 at 7:32 PM Jeff Law <law@xxxxxxxxxx> wrote: > > > On 9/28/20 8:50 AM, Jan Kratochvil wrote: > > > > DWARF standard sometimes makes mistakes, for example .debug_pubnames and > > .debug_pubtypes were never really usable and DWARF-5 removed them. It may be > > perfectly possible the DWZ extension of DWARF-5 will be removed in DWARF-6 or > > future DWARF standards as it turns out it is not worth the format complexity. > > That some text has been accepted into the DWARF standard does not mean much. > Sure. We all make mistakes and standards bodies are no different. If > you feel strongly that it was a mistake, then get involved in the > process and try to correct it. > > > > It is all about engineering effort. I agree if the support of DWZ was trivial > > (or there were unlimited engineering resources) then DWZ is really better than > > -fdebug-types-section (except it would need a DWZ tool with less bugs and > > better coding practices). But reality shows the DWZ support is not trivial > > engineering resources for Fedora are very limited and so we have to decide > > whether the serious effort to support DWZ is better spent on DWZ or on making > > the debuggers better/really usable. > > > > Given how much you propose DWZ apparently the 3.3% Fedora distribution size > > increase (if DWZ is dropped) is considered as too much. Obviously if the size > > increase was just let's say 0.1% it would be acceptable to drop DWZ - do you > > agree? So where is your size limit where the years-effort of supporting DWZ is > > worth it? I would say my limit would be maybe 20%, far above the 3.3%. > > Putting my Red Hat hat on, I get pushback from PM on *any* size > increases in the RHEL space. While I often question the technical > reasons behind why our customers are pushing for marginal (IMO) > improvements, reality is they care. As much as we'd like to be in a > world were a 1% increase in distro size doesn't matter, that's not the > actual world we live in. > > And our RHEL customers absolutey do care about the size of debuginfo > becuause it affects link times. > > > Anyway, I'll put my Fedora hat back on :-) > > I feel like it's worth giving my perspective here as someone who has done similar work in other distributions. Because of how little debuginfo is used *in general*, every bit of space saving matters. The dwz technology took so long to be adopted because the rpm support never made it upstream. It took some poking and prodding to finally get it upstreamed for RPM 4.14, and in doing so, distros started using it because they were comfortable with relying on the feature. I don't think people realize how scary the debuginfo code actually is for us "plebs" wanting to support it while having no knowledge or hope of understanding the depths of it all. It's a very esoteric system. Most of the distributions were unwilling to pull in an out-of-tree patch out of fear of being stuck supporting it alone. For RPM distributions, once it was mainlined, that fear was gone. The Debian distribution family had the benefit of being able to reimplement the whole system initially based on how it works in Fedora for them, and once they did that, it was inherited by that entire branch of Linux distributions. I personally worked on enabling advanced debuginfo generation features in rpm for OpenMandriva when I helped migrate them to RPM 4.14 and DNF[1]. The only real trouble was with Clang being broken with split debuginfo+debugsource with Clang/LLVM 7[2], which was fixed after upgrading to Clang/LLVM 10[3]. The quality of life improvements with advanced rpm debuginfo generation and dwz have made it tremendously easier for me and others to be able to ship debuginfo data for more packages. And as developers *need* that data to be able to... well, debug things, it comes in handy having it everywhere. I have also helped with bringing this to other distributions, but I feel that my story here with OpenMandriva is particularly important since we seem to be having a tug-of-war between the GCC and LLVM toolchain teams. [1]: https://www.openmandriva.org/en/news/article/switching-to-rpmv4 [2]: https://github.com/OpenMandrivaSoftware/rpm-openmandriva-setup/commit/a54ffd78b1eaeb1752cb7894ffdb266fb5b85311 [3]: https://github.com/OpenMandrivaSoftware/rpm-openmandriva-setup/commit/5b432a2d3d1c9c4aefbab04f937aed8b8c4618d8 [...] > > > By that LLVM dead DIES reduction talk I wanted to just show apparent nobody > > cares too much about few percents of the *-debuginfo.rpm size - otherwise it > > would be already coded/used. Or if there wasn't DWZ Fedora could already > > switch to DWARF-5 which saves probably more size than DWZ does. > > I wasn't even aware we had dead dies. THat doesn't mean I don't care, > it just means I wasn't aware. Others may be aware, but have higher > priority items on their TODO lists. Stating that "nobody cares too much > ..." isn't helpful. > For the record, Mark has started implementing DWARF-5 support in dwz: https://sourceware.org/git/?p=dwz.git;a=log I think I would rather like to see a Change proposal to switch to DWARF-5 for Fedora 34, especially since it looks like dwz will be ready for it. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
