On Mon, 05 Oct 2020 08:28:03 +0200, Florian Weimer wrote:
> Why do you think that? Using debuginfo for perf and the like seems to
> be much more common than actual debugging, based on what I see
> downstream.
OK, interesting, thanks for the info. Still that does not change anything with
btrfs zstd. btrfs zstd would save on-disk size ~50% (I did not measure zstd
for Fedora distro, zlib saves on Fedora distro 52%) compared to DWZ's on-disk
size saving of 20% (or just 10% if one makes some non-DWZ optimizations in
addition to -fdebug-types-section).
> > The problem is that you have to wait for minutes for GDB to print anything.
>
> Is this about slow tab completion?
No. GDB always converts DWARF->IR (=expands) for whole CUs (Compilation Units).
Moreover for some constructs GDB requires complete type definition which makes
CUs dependent on other CUs. So in practice accessing one variable will expand
around 50 CUs. And each CU is nowadays huge for real C++ templatized programs.
In other cases (such as in lambda functions) GDB even expands completely all
CUs. That is probably some GDB bug. But it makes GDB to eat 20+ GB of memory
and several minutes of runtime on fast machines to print a variable.
Compared to that LLDB expands only one DIE and it is done. But LLDB needs to
know where the DIE is. This is why LLDB needs .debug_names index and not
.gdb_index which does not contain DIE offsets. And this is why .gdb_index is
easy to update for DWZed DWARF but for .debug_names there is currently even no
DWARF specification how to make it compatible with DWZ. DWZ .debug_names index
has to express two CUs for each DIE:
(1) DW_TAG_partial_unit where the DIE is located in the DWARF file
(and whether it is in DWZ common file or not)
(2) DW_TAG_compile_unit which did DW_TAG_imported_unit that
DW_TAG_partial_unit)
LLDB DWZ support had to extend its in-memory index this way but it does waste
LLDB memory+runtime on all OSes not using DWZ (=most of the LLDB use - for
Android/iOS/OSX).
> > It is faster to add cout<<, recompile and rerun the program (with clang+lld as
> > with g++ it takes more than 3x as much time) than to wait for GDB. LLDB would
> > sure print it immediately but it is incompatible with Fedora DWARF. Enjoy.
>
> I can't use LLDB because it does not support thread-local variables.
I have this item in my LLDB TODO list (and I even fixed the TLS support in GDB
in the past). But without DWARF (DWZ) support it makes no sense to support TLS.
So I rather returned to working on the DWZ support saving 1.8% of distribution
size wasting 2 years on it and probably going to continue wasting more
forthcoming years on those 1.8% of distribution size.
> Not even initial-exec variables, which could be implemented without
> peeking at glibc internals.
Yes, a lot of useful things could be working if we did not have to waste time
on useless stuff.
Jan
_______________________________________________
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
