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).
Indu
