>>> The potential savings here didn't seem worth the effort of adding a
>>> pass over another table to assign slots in .debug_addr. In practice,
>>> we're seeing very few slots zeroed out here.
>
> And how many duplicate entries? What strategy does Cary's patch use to
> avoid those?
I picked a compilation unit from one of our internal applications with
one of the largest .debug_addr sections, and counted up the
.debug_addr entries:
Total count: 320,083
Unique entries: 8022
Unused entries (i.e., removed by resolve_addr): 13
Total refs to ".LVL" symbols: 313,554
Unique ".LVL" symbols: 3288
Entries after removing just duplicate ".LVL" refs: 9817
After the ".LVL" symbols, the most repeated entries were these:
298 .quad _ZdlPv
13 .quad _Znwm
12 .quad memmove
Nearly all the remaining repeated entries were ".LC" (constant def)
symbols (at most 6 of each). We have a lot of entries for ".LFB"
(function begin) and ".LBB" (block begin) symbols, but no duplicates
for any of these.
I'm working on a follow-up patch to eliminate the duplicate references
to ".LVL" symbols by keeping a direct-lookup table in
dwarf2out_var_location. That will eliminate 310,266 of the 312,061
duplicates (99.4%) without using a hash table. With that patch, we'll
have only a 22% overhead due to duplicate entries. (For this source
file, at least -- I've seen similar numbers for a few other
randomly-chosen sources, but I haven't done the same detailed analysis
for them.)
I'm also planning to do another later patch to generate location lists
using the new DW_LLE_offset_pair_entry type for the .debug_locs.dwo
section. This entry format uses offsets relative to the function's
low_pc (or a base address selection entry), which (I think) will
eliminate .debug_addr entries for ".LVL" symbols entirely. I think it
should also get rid of most of the ".LFB" references as well. GDB
isn't ready for that yet, so that one will come later.
I'm trying to eliminate all .debug_addr entries that could be replaced
by an offset relative to either another .debug_addr entry or an
address in a range list.
> I was thinking that the context of the reference would determine whether you
> want a direct or indirect reference, in a way that would be clear when we go
> to write out the reference. But if that isn't convenient, I don't mind
> determining it when we build the reference.
>
> The added documentation for force_direct tells me what it means, but not
> when you would want to pass true or false. What is the pattern here?
We use force_direct when we're adding an attribute to a DIE in a
skeleton compile unit or type unit (which will be in the .o file).
It's false everywhere else (i.e., when the DIE is going into the .dwo
file).
-cary
