Re: [3/3] unconditionally call via SYMBOL_COMPUTED_OPS

[Tom Tromey <tromey@redhat.com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> Without the full virtualization / unconditional calls via
Jan> SYMBOL_COMPUTED_OPS I do not understand this patch and I am against
Jan> it.

This was troubling me yesterday and I finally remembered that I did
implement the needed change, but in a non-obvious way.  I now think
either your analysis is incorrect or I didn't understand it.

Basically, it is register_symbol_alias_impl that does the work.
For a function, dwarf2_symbol_mark_computed uses the _block indices,
e.g.:

+      SYMBOL_ACLASS_INDEX (sym) = (is_block
+				   ? dwarf2_loclist_block_index
+				   : dwarf2_loclist_index);

These are registered as aliases of LOC_BLOCK:

+  dwarf2_loclist_block_index = register_symbol_alias_impl (LOC_BLOCK);

What this means is that the resulting symbol will have LOC_BLOCK and a
SYMBOL_LOCATION_BATON, but SYMBOL_COMPUTED_OPS will be NULL.  So, the
various calls via the vtable will never be taken.

Jan> I had problems cleaning up patch 2/2 now because issues brought in
Jan> by this patch 3/3 and I find this patch 3/3 is the inappropriate
Jan> one.

Ah, I see.  Your follow-on patch restored the vtable in all cases.
This isn't correct according to the approach of patch #3 and the design
implied by the comments and the PR.

I tend to like the approach taken in the patch because it is more
flexible.  If you disagree I would like to understand why.

Tom