On October 18, 2019 1:59:36 PM GMT+02:00, Pedro Alves <pal...@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.alc...@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