Re: [PATCH v2 04/13] [gdb/symtab] Factor out m_deferred_entries usage

[Tom de Vries <tdevries@suse.de>]

On 12/12/23 19:39, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
> 
> Tom> Factor out usage of cooked_indexer::m_deferred_entries in new member
> Tom> functions defer_entry, handle_deferred_entries and resolve_deferred_entry.
> 
> I don't mind this, but when reading through the whole series, it seems
> like the code has to now iterate over a lot of the entries trying to fix
> up the parentage later.
> 
> I wonder then about just sticking this info directly into the
> cooked_index_entry object, and then doing fixups directly on these in
> the shard.
> 
> That is, instead of keeping separate "deferred" entries, just making
> ordinary entries.  cooked_index_entry::parent_entry could be a union
> holding either the parent (if known) or a CORE_ADDR; and then there
> could be a new flag in cooked_index_flag_enum indicating which one is in
> use.
> 
> Then I think parent_map::deferrred also would not be needed.
> 
> I'm still kind of mid-reading so my apologies if this doesn't really
> make sense.

I've also considered something like this: rather than deferring creating 
entries, creating them immediately with some marker that work is left to 
be done.  My initial though there was to use parent_map::deferred as 
parent, and then keep lists of:
...
struct {
   CORE_ADDR get_parent_from_here;
   cooked_index_entry **patch_parent_here;
};
...

The union+flag approach would also work but doesn't offer a way to 
iterate over them quickly, which might matter for large shards.  Though 
we could do a side-table approach I suppose.

We could choose to not care about such lists (in which case you'd need 
the union+flag solution) and resolve these on demand, but then that'll 
have to take care of cycle detection, so atm I'm not convinced that's a 
good idea.

Thanks,
- Tom