This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [3/3] unconditionally call via SYMBOL_COMPUTED_OPS
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 08 Feb 2013 04:52:10 -0700
- Subject: Re: [3/3] unconditionally call via SYMBOL_COMPUTED_OPS
- References: <871udlhzzb.fsf@fleche.redhat.com> <20130207163233.GA15297@host2.jankratochvil.net>
>>>>> "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