On 9/30/20 3:50 AM, Jan Kratochvil wrote: > On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote: >> But the GCC community >> doesn't really test that option and it's known to be broken with LTO. > I haven't seen any GCC PR for -fdebug-types-section being broken with LTO. I'm not aware of one either. But as Jakub has previously pointed out debug-types-section is disabled when LTO is enabled. I don't know the details of why that is done. > > During one abigail diff I did not see any difference. I plan to run a full > distribution abigail massrebuild+check as stated in the Change to exclude any > possible incompatibilities. That would discover unfiled GCC problems with > -fdebug-types-section. > > Also I do not see why fixing -fdebug-types-section should be anyhow difficult > if the compiler can produce -fno-debug-types-section. I can also write > postprocessor to get -fdebug-types-section if GCC is unable to do that. > That would sure lose the -fdebug-types-section compilation time performance > benefits. > > >> And, not surprisingly, our team has had significant input on the options >> we're using *and* the GCC implementation of those options. We make >> recommendations based on our experiences. That same experience would lead us >> to recommending against -fdebug-types-section at this time. > I think I have also some DWARF experience. Could you suggest what is wrong on > -fdebug-types-section? Your best bet is to discuss with Jakub and perhaps Jason. They're far more familiar with the debuginfo generation than I am. > > >> It would certainly be good to improve the on-disk distro size. > OK, going to file a Change to enable gcc -gz option (zlib section compression) > as that will reduce on-disk *.debug size by 52.84%! Then we can disable both > DWZ and -fdebug-types-section as those become pointless then. Note Mark's reply in the other thread. Section compression has significant tradeoffs. > > >> So the only paths forward I see are to either fix -fdebug-types-section or >> improve dwz. > And obviously much easier is to fix -fdebug-types-section than DWZ (if there > are really any bugs in -fdebug-types-section, there are known bugs nobody > wants to fix in DWZ). I think you're making an unsubstantiated leap here. Neither of us know what's wrong with GCC LTO and debug-types-section and others are working on dwz. > > >> Putting my Red Hat hat on, I get pushback from PM on *any* size increases in >> the RHEL space. > When we start talking about RHEL (and CentOS) DWZ is completely pointless then > as DWZ there saves only 0.28% of *-debuginfo.rpm (20MB of 7.2GB). > Therefore approx. 0.14% of the distribution size. Umm, we're fighting with PM these days over things in the 10M range. So, no it's not pointless. > > >> 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. > Unfortunately DWZ cannot decrease RHEL size by that 1%. I'm not asking it to. I'm saying that sizes matter, even in cases where you think they shouldn't. > > >> And our RHEL customers absolutey do care about the size of debuginfo >> becuause it affects link times. > System debuginfo format does not affect link times. Using DWZ during linking > customer's applications definitely only increases linking time as it is an > extra step. Not sure what do you talk about. Most customers don't use dwz. But they consume its output for the RPMs that we provide. Jeff _______________________________________________ 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
