Re: Type representation in CTF and DWARF

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, Oct 11, 2019 at 1:06 AM Indu Bhagat <indu.bhagat@oracle.com> wrote:
>
>
>
> On 10/09/2019 12:49 AM, Jakub Jelinek wrote:
> > On Wed, Oct 09, 2019 at 09:41:09AM +0200, Richard Biener wrote:
> >> There's a mechanism to get type (and decl - I suppose CTF also
> >> contains debug info
> >> for function declarations not only its type?) info as part of early
> >> debug generation.
> >> The attached "hack" simply mangles dwarf2out to output this early info as the
> >> only debug info (only verified on a small .c file).  We still have things like
> >> file, line and column numbers for entities (not sure if CTF has those).
> >>
> >> It should be possible to "hide" the hack behind a -gdwarf-like-ctf or similar.
> >> I guess -g0.5 isn't desirable and we've taken both -g0 and -g1 already...
> >> (and -g1 doesn't include types but just decls).
> > Yeah.  And if location info isn't in CTF, you can as well add an early
> > return in add_src_coords_attributes, like it has one for UNKNOWN_LOCATION
> > already.  Or if it is there, but just file/line and not column, you can use
> > -gno-column-info.  As has been mentioned earlier, you can use dwz utility
> > post-linking instead of -fdebug-types-section.
> >
> >       Jakub
>
> Thanks for your pointers.
>
> CTF does not encode location information. So, I used early exit in the
> add_src_coords_attributes to avoid generation of location info (file, line,
> column). To answer Richard's question, CTF does have type debug info
> for function declarations and the argument types. So I think with these
> changes, both CTF and DWARF generation will emit debug info for the same set of
> types and decl.
>
> Compile with -g -gdwarf-like-ctf and use dwz -o <binary_dwz> <binary> (using
> dwz compiled from the master branch) on the generated binaries:
>
> (coreutils-0.22)
>       .debug_info(D1) | .debug_abbrev(D2) | .debug_str(D4) | .ctf (uncompressed) | ratio (.ctf/(D1+D2+0.5*D4))
> ls   30616           |    1136           |    21098       | 26240               | 0.62
> pwd  10734           |    788            |    10433       | 13929               | 0.83
> groups 10706         |    811            |    10249       | 13378               | 0.80
>
> (emacs-26.3)
>       .debug_info(D1) | .debug_abbrev(D2) | .debug_str(D4) | .ctf (uncompressed) | ratio (.ctf/(D1+D2+0.5*D4))
> emacs-26.3.1 674657  |    6402           |   273963       |   273910            | 0.33
>
> I chose to account for 50% of .debug_str because at this point, it will be
> unfair to not account for them. Actually, one could even argue that upto 70%
> of the .debug_str are names of entities. CTF section sizes do include the CTF
> string tables.
>
> Across coreutils, I see a geomean of 0.73 (ratio of
> .ctf/(.debug_info + .debug_abbrev + 50% of .debug_str)). So, with the
> "-gdwarf-like-ctf code stubs" and dwz, DWARF continues to have a larger
> footprint than CTF (with 50% of .debug_str accounted for).

I'm not convinced this "improvement" in size is worth maintainig another
debug-info format much less since it lacks desirable features right now
and thus evaluation is tricky.

At least you can improve dwarf size considerably with a low amount of work.

I suspect another factor where dwarf is bigger compared to CTF is that dwarf
is recording typedef names as well as qualified type variants.  But maybe
CTF just has a more compact representation for the bits it actually implements.

Richard.

> Indu
>