On Fri, Oct 11, 2019 at 1:06 AM Indu Bhagat <indu.bha...@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 >
