On Mon, Sep 28, 2020 at 05:15:16PM +0200, Jan Kratochvil wrote:
> On Mon, 28 Sep 2020 12:42:33 +0200, Jakub Jelinek wrote:
> > On Mon, Sep 28, 2020 at 12:31:59PM +0200, Mark Wielaard wrote:
> > > 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.
> >
> > And note that GCC already does implement
> > -feliminate-unused-debug-{symbols,types} which are enabled by default and
> > are (at least in my eyes) sometimes too aggressive, so by eliminating even further
> > DIEs the debug experience might be even worse.
>
> git clone git://git.jankratochvil.net/massrebuild
> ./dwarfredundant lldb-debuginfo-11.0.0-0.2.rc3.fc34.x86_64/usr/lib/debug/usr/lib64/liblldb.so.11.0.0-11.0.0-0.2.rc3.fc34.x86_64.debug
So, was this compiled by GCC or clang?
If GCC, I don't see how one could end up with low_pc of 0 unless it is a
comdat function where there is a DIE from the TU that actually was selected
by the linker, or some other copy that wasn't selected.
A way out of this could be either to use comdat .debug_info etc. sections
(but that would result in quite large increase of *.o file sizes), or let
the linker or a tool like DWZ discard or simplify such DIEs.
I don't see how could you see at compile time that the linker will not
choose the particular copy.
Jakub
_______________________________________________
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
