This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Type representation in CTF and DWARF
On 17 Oct 2019, Richard Biener verbalised:
> On Thu, Oct 17, 2019 at 7:36 PM Nick Alcock <nick.alcock@oracle.com> wrote:
>>
>> On 11 Oct 2019, Indu Bhagat stated:
>> > 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
>
> Btw, for a fair comparison you have to remove all DW_TAG_subroutine
> children as well since CTF doesn't represent scopes or local variables
> at all (nor types only used by locals). It seems CTF only represents
> function entry points.
Good point: I'll have to hack up a DWARF trimmer to do this comparison
properly, I think. (Though CTF does represent global variables,
including file-scope statics.)
In most cases local types etc are a fairly small contributor to the
total volume -- but macros can contribute a lot in some codebases. (The
Linux kernel's READ_ONCE macro is one I've personally been bitten by in
the past, with a new local struct in every use. GCC doesn't deduplicate
any of those so the resulting bloat from tens of thousands of instances
of this identical structure is quite incredible...)