On Fri, 25 Sep 2020 13:56:47 +0200, Jakub Jelinek wrote:
Jan had probably problems getting his DWZ support upstreamed into
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
Simplifying Fedora toolchains is more constructive than supporting complicated
format with no benefits.
-fdebug-types-section in GCC is pretty much unmaintained, almost
really using it,
According to Richard Biener from GCC -fdebug-types-section is a normally
supported GCC feature:
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
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
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.