The DWARF .debug_info section generated by the current Go compiler
does not make use of sibling links at the moment. As gc-generated
DWARF DIE's begin to get more substantial/complicated, this will make
it more time-consuming for debugger as it tries to locate the DIE for
a specific entity within the .debug_info section.
It might make sense to look into introducing siblings to DIEs such as
the subprogram DIE and possibly the structure type DIE (for use in cases
where you have a struct with a large number of members).
Note that such a change would provide little benefit for Delve users
without a corresponding change to Delve (looking at the Delve tip
source code, it appears that the DWARF reader is not set up to exploit
I know at least 3 ways of getting around DWARF: sibling links, .debug_pubtypes, .debug_names (DWARF5) and I think there are some hash table variants floating around. Do you have any context on which is the most bestest? We already have .pubtypes and .pubnames, the latter of which should cover finding functions.
Looking at the source for Delve, I see code that walks the entire .debug_info section, looking for interesting bits and the calling "reader.SkipChildren()" in situations where the children are not interesting. Example:
I should add to my last comment-- my original remark about needing a corresponding change in Delve to exploit sibling links was incorrect; delve is getting that for free by using Go's debug/dwarf package.