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
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.