Issue 031001.1: Index Info

Author: Chris Quenelle
Champion: Chris Quenelle
Date submitted: 2003-10-01
Date revised:
Date closed:
Type: Extension
Status: Closed
DWARF Version: 3
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 <jimb@redhat.com>

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
this is.

------------
Michael Eager

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.




--------------

Daniel Jacobowitz

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?


  Chris Quenelle
  > 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.