[Bug default/20369] Support DW_TAG_type_unit

["andrew.c.morrow at gmail dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #21 from andrew.c.morrow at gmail dot com ---
(In reply to Mark Wielaard from comment #17)
> (In reply to andrew.c.morrow from comment #14)
> > I'd not heard that -fdebug-types-sections was disfavored
> 
> It is disabled by default since it splits the DIE tree into separate data
> sections (.debug_info vs .debug_types) which confuses some tools and because
> dwz compression gives bigger savings.
> 
> > As I mentioned elsewhere, I am also experimenting with
> > -Wl,--compress-debug-sections=zlib-gabi, which I think is more or less the
> > same thing as using 'dwz'. The improvements there are quite nice.
> 
> As Ben mentioned ELF zlib section compression is completely independent from
> using debug_types or dwz. It is traditional lossless data compression that
> doesn't know anything about the underlying DWARF data. dwz also works on
> multiple DWARF files, making it possible to extract all common DWARF data
> into a separate shared file. That makes it particular effective when a
> program/package contains multiple shared libraries that share common data
> structures.
> 
> In general I would recommend against using ELF section compression. Again
> some tools don't know how to handle such compressed ELF sections and it
> trades disk space for memory space and time. Which might not matter much for
> libabigail which uses elfutils libdw and the newest versions should make the
> section compression transparent. But for tools that only need small parts of
> the DWARF data and that require fast startup for like profiling, tracing or
> interactive debugging sessions it slows down startup and blows up memory
> (they can no longer simply map the ELF files into memory and only access
> those parts they need, but need to copy and decompress all data at startup).
> 
> A better alternative is what most distros do compressing the whole package
> for transport, but make sure the full files are installed. Using
> file/package level compression on separate debuginfo files also allows more
> effective compression algorithms like lzma which compress much better than
> zlib.

Thank you for the information on dwz. I actually just tried it out, but it
doesn't seem to work for me:

$ dwz -m common.debug ./mongo.debug ./mongod.debug ./mongos.debug
dwz: Allocatable section in ./mongo.debug after non-allocatable ones
dwz: Allocatable section in ./mongod.debug after non-allocatable ones
dwz: Allocatable section in ./mongos.debug after non-allocatable ones
dwz: Too few files for multifile optimization

I think what is happening here is it has bailed out on each of the three files,
and then sort of reasonably concludes that the remaining files, of which there
are none, are not enough to work with.

A quick google around for the 'dwz: Allocator section..' message did not lead
to anything very promising.

Any suggestions on how to debug this, or for where to raise this question?

I'm also a little curious about the relationship between dwz and the whole
'debug fission' project and its tool dwp. Is -gsplit-dwarf still a think of
interest?

There seems to be a lot of great work out there about minimizing debug info,
but not a lot of guidance on which techniques are the right ones to use, and
which have become obsolete.

Anyway, here is the info on the version of dwz I have. The local system is
Ubuntu 16.04:

$ dwz --version
dwz version 0.12
Copyright (C) 2001-2012 Red Hat, Inc.
Copyright (C) 2003 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

What is the appropriate forum/project for working through issues with dwz? It
doesn't seem to be part of binutils.

-- 
You are receiving this mail because:
You are on the CC list for the bug.