Type representation in CTF and DWARF

[Richard Biener]

On October 18, 2019 1:59:36 PM GMT+02:00, Pedro Alves <palves@redhat.com> wrote:
>On 10/17/19 7:59 PM, Nick Alcock wrote:
>> 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.)
>
>Wouldn't it be possible to extend the -gdwarf-like-ctf hack to skip
>emitting those things?

Sure. 

>> 
>> 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...)
>> 
>
>Sounds like something that would be beneficial to do with DWARF too.

Otoh those are distinct types according to the C standard and since dwarf is a source level representation we should preserve this (source locations also differ). 

Richard. 

>Thanks,
>Pedro Alves