This is the mail archive of the
mailing list for the Archer project.
Re: [RFC] Proposal for a new DWARF name index section
>>>>> "Daniel" == Daniel Jacobowitz <firstname.lastname@example.org> writes:
Tom> I agree we could read the DIE and look at the tag. However, that means
Tom> disk access to read the DIE, and disk access to read in the abbrev
Tom> table. That seems very expensive for what is supposed to be a quick
Tom> index lookup.
Daniel> If you had a sufficiently smart consumer that it didn't need to keep
Daniel> all of .debug_info in memory all the time, then this would have some
Daniel> measurable impact.
We now mmap .debug_info, and I've been assuming that this would not
actually touch the disk until we tried to read the data. I didn't try
to verify this yet, though.
Also, it looks possible for us to defer even mapping .debug_info and
other sections until some symbols are actually needed. (At least, this
is true in the situation where the index describes every CU. If we are
missing an entry then we do more work.)
Daniel> If you don't read this data off disk when reading the pubnames, you'll
Daniel> have to do it the first time one of them is referenced, anyway. This
Daniel> is separate from parsing all the DIEs (psymtabs), which is much more
I think the question is whether searches requiring the tag occur often
enough that they would begin to eat into the performance gains.
Unfortunately this question isn't separable from the question of how
expensive it is to decide whether pubnames is actually usable.
I suppose this can be answered experimentally, if we assume some use
Daniel> Someone suggested on gdb-patches that GDB could generate and cache the
Daniel> pubnames table. It follows that a separate packaging tool could do so
Daniel> also. Something to consider... during separate debug file generation,
Daniel> for instance.
Yeah, or at least extend dwarflint to verify the output, assuming it