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