Re: New Proposal: Global Types section

[James Cownie <jcownie at etnus dot com>]

>   Well I can understand why a Dwarf consumer might like to have this and I
>   can see how it can serve a purpose similar to .debug_pubnames, but I
>   don't see it as that big of an improvement for the following reasons:
> 
>     - With or without the .debug_pubtypes section, all the information
>       necessary to resolve the incomplete definition is present.

Agreed.

>     - With or without the .debug_pubtypes section, Dwarf2 consumers will
>       still have to perform a name matching operation.

Agreed.

>     - No new information is being added.  The new section essentially
>       replicates existing information into an "easy to find" spot.

Agreed, this is exactly the same as the other sections which exist to
make it easier to find things by name.

No one has claimed that it adds new information. What it does is to
make existing information easier to use, exactly as do the other
.debug_pub* sections.

>     - Ladebug probably would not use it any time soon, if ever, given that
>       it will most likely continue to do at least some parsing at load time.

The whole of this proposal has the same justification as already
exists in the DWARF spec for the .debug_pubnames section. No more and
no less. 

If one has to skim the whole of the top-level dwarf one can, it's no
big deal, it's just that doing that _has_ to be slower than not doing
it ! (Especially since DWARF 2 doesn't require the sibling pointers,
so one ends up having to parse the syntax, if not the semantics, of
more stuff than one would hope simply to skip over it).

If there really is a requirement for 64 bit offsets into DWARF
sections, then there are presumably DWARF sections with > 32 bit
offsets. Mapping those and walking over the top level information in
them is going to take user visible time at startup. If we can avoid it
so much the better.

> A simpler proposal that might achieve the same benefit where this technique
> is deemed worthwhile might be to modify the specification of .debug_pubnames
> to allow the names of types to be included, rather than just objects and
> subroutines. Is there any interest in persuing this variation?

Well you could probably do that, but it's likely to break existing
consumers which expect only text or data symbols in .debug_pubnames.

Don't forget that this proposed section is optional, (like
.debug_pubnames), my view is that it would be useful for speeding up
startup, and that that will become more and more important in the
future if images are really going to grow to the extent that 64-bit
DWARF section sizes suggest. So, I'd like to have a specification here
that we can use when we need it... 

Of course there are other entirely orthogonal and possibly more
elegant approaches to the huge file size issues (such as that used by
SUN in Elf/Stabs, where most of the debug information is left in the
object files, and _only_ index style information is included in the
executable). Adding that style to DWARF would be a much bigger deal,
though.

-- Jim 

James Cownie	<jcownie@etnus.com>
Etnus, Inc.     +44 117 9071438
http://www.etnus.com