* Jan Kratochvil:
On Tue, 29 Sep 2020 22:29:44 +0200, Mark Wielaard wrote:
> I was just discussing that recently with the Hotspot Perf GUI
> maintainer. And we concluded that if .debug files would be compressed
> then we would need an uncompressed cache somewhere. The issue with
> having the on-disk debuginfo files compressed is that for
> debugger/tracing/profiling tools it incurs an significant
> decompression time delay and extra memory usage. Especially for a
> profiling tool that only needs to quickly get a little information it
> is much more convenient to be able to simply mmap the .debug file,
> check the aranges and directly jump to the correct DIE offset. See
> e.g.
https://github.com/KDAB/hotspot/issues/115
First is is a marginal use case.
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.
The problem is that you have to wait for minutes for GDB to print
anything.
Is this about slow tab completion?
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.
Not even initial-exec variables, which could be implemented without
peeking at glibc internals.
Thanks,
Florian
--
Red Hat GmbH,
https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill