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.

I would think the indices (debug_pubtypes or debug_names) are better than providing sibling links?

Debug_names seems slightly better than debug_pubtypes/debug_pubnames because users only need to look up in one index instead of two, but it's also newer so it's presumably less widely supported yet.

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:

https://github.com/derekparker/delve/blob/5c9b2009cab214c1f912a2d8c6c89eec9f3ada2b/pkg/proc/types.go#L142

If we added sibling links to the GC-generated DWARF, I'd imagine that this routine would get a lot faster (without any changes to the code itself, I should add).

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.

Note that routine is only executed once on startup. And #19340 is a far bigger contributor to slow start up times at the moment.