Dwarf2 has the notion of "index" information stored in sections like
".debug_pubnames", ".debug_varnames", etc. Some vendors have
added additional similar sections.
This information is used as an index into the full .debug_info
data so that you don't have to read all the .debug_info section
until you need some piece of it.
If a vendor could extend or modify the kind of index information.
without defining new ELF sections, that would be better.
Has it been suggested to create a new section called something like:
".debug_info_index" which has the same format as ".debug_info"
except it only includes the globally visible types/variables?
(Along with DIE pointers into the .debug_info section, and/or pointers
to the containing CU in the .debug_info section)
It could bedefined loosely so vendors can put whatever kind of index
information they want inside it. Using the same (or similar)
structure that's found in ".debug_info".
Basically the same info as what's in .debug_pubnames/.debug_varnames
only in a more extensible format?
Jim Blandy <firstname.lastname@example.org>
I kind of like this idea.
Dwarf >=2 dies are a pretty darn nice format. You can invent new
attributes and tags, and everything's optional, with pratically no
space consequences. I really began to appreciate ies when I was
putting together the proposal for die-based macro information (which
I've never gotten around to implementing...).
It would make slurping up the indices a bit more compute-intensive,
but GDB doesn't use them, so I have no sense for how much of an issue
My first impression is that while it would be more extensible (although
without details it's difficult to say), it would require more processing.
The .debug_pubnames and .debug_aranages are simple unstructured lists,
which make them very easy to search.
On the other hand, wouldn't this allow us to use .debug_str for the
strings in .debug_pubnames - a potentially big space savings, esp. with
a linker which merges constants?
> It would make slurping up the indices a bit more compute-intensive,
> but GDB doesn't use them, so I have no sense for how much of an issue
> this is.
Very small, I think. I've been meaning to implement this sort of thing
in GDB, and .debug_info_index would be pretty much ideal.
Closed due to lack of proposal.