FYI DWARF .gdb_index-like proposal by Apple

FYI DWARF .gdb_index-like proposal by Apple

[Jan Kratochvil]

Hi,

just a highlight of submitted DWARF extension with new indexes:
	http://www.dwarfstd.org/ShowIssue.php?issue=130410.1&type=open

I have not checked yet if it is sufficient for GDB instead of .gdb_index.


Jan

Re: FYI DWARF .gdb_index-like proposal by Apple

[Jan Kratochvil]

On Mon, 27 May 2013 15:34:10 +0200, Jan Kratochvil wrote:
> just a highlight of submitted DWARF extension with new indexes:
> 	http://www.dwarfstd.org/ShowIssue.php?issue=130410.1&type=open
> 
> I have not checked yet if it is sufficient for GDB instead of .gdb_index.

In the proposal ".debug_names" entries for DW_TAG_variable should support also
TLS variables (which do not use DW_OP_addr required by the proposal).

Compared with GDB .gdb_index:
	http://sourceware.org/gdb/current/onlinedocs/gdb/Index-Section-Format.html#Index-Section-Format

(1) The proposal does not have any address -> name index;
    there is .debug_aranges but that is probably deprecated by the proposal
    above plus it has other issues:
    http://www.dwarfstd.org/ShowIssue.php?issue=100430.1&type=open
    http://www.dwarfstd.org/ShowIssue.php?issue=100430.2&type=open

(2) The proposal symbol names are either fully qualified mangled or just
    DW_AT_name; .gdb_index uses demangled fully qualified name.
    The problem is GDB cannot mangle names so GDB would have to make
    the look up via DW_AT_name where may occur many lookup collisions.

(3) .gdb_index has single hash table;
    the proposal uses 3 hash tables, this is less efficient.
    One should use DW_ATOM_die_tag there anyway to look up only symbol kinds
    GDB is interested in - .gdb_index uses it with performance gain in:
    http://sourceware.org/ml/gdb-patches/2012-06/msg00607.html
    And with DW_ATOM_die_tag present the 3 hash tables could be merged.

(4) .gdb_index provides global/static flag for each symbol;
    one could use new DW_ATOM_* kind but that costs 1 byte, not 1 bit;
    one wants to look up only global symbol first while there are usually many
    static symbols of the same name, performance data is in the same URL above.


Jan

Re: FYI DWARF .gdb_index-like proposal by Apple

[Tom Tromey]

Jan> just a highlight of submitted DWARF extension with new indexes:
Jan> 	http://www.dwarfstd.org/ShowIssue.php?issue=130410.1&type=open
Jan> I have not checked yet if it is sufficient for GDB instead of .gdb_index.

Jakub asked me to send my notes on this to the public list.


The big issue I found with it is that it doesn't specify name
canonicalization.  It just defers to DW_AT_name.  This would probably
prevent us from using it in gdb.

I think either name canonicalization is needed to successfully look up
template instantiations, or everything has to be simple names; but then
that seems to require multiple trips through the index to look anything
up.

Perhaps the intent is that readers can use the demangler on the mangled
form of names.  However, this is quite expensive.  I think it would
defeat the purpose of the index.


It wasn't clear to me how this interacts with dwz.


.gdb_index has a section that indicates the CU offsets in .debug_info.

This is needed because you cannot read a DIE without first reading the
CU's header.  Various things in DWARF depend on data in the header.

The proposed index seems to handle this via DW_ATOM_cu_offset.  However
this seems somewhat bloaty given that this is required in order to be
correct; at least without some other bit saying "please pretend all CUs
have the same header settings".

Perhaps the idea is that CU boundaries are to be determined from
.debug_aranges.


It wasn't clear to me how this index handles duplication.  E.g. nearly
every CU defines "int".  gdb's index is defined to squash these
duplicates.


I'm not convinced that the treatment of anonymous namespaces is what
readers want.  I don't have a counter-proposal.  I think .gdb_index
probably gets this wrong as well.


Naturally I may have misunderstood things.  I welcome your insight.

Tom