Re: [patch 02/12] entryval: Basic parameter values recovery

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Tue, 19 Jul 2011 16:19:00 +0200, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> 
> Jan> +extern struct cleanup *make_cleanup_htab_delete (htab_t htab);
> 
> Just a minor additional cleanup -- dwarf2read.c:cleanup_htab can now be
> removed.  I can do this after the patch goes in if you like.

done.


> Jan> +	    error (_("DWARF-2 expression error: DW_OP_GNU_entry_value is "
> Jan> +		     "supported only for single DW_OP_reg* "
> Jan> +		     "or for DW_OP_breg*(0)+DW_OP_deref*"));
> 
> I'm a little surprised that DW_OP_GNU_regval_type isn't included here;
> but I suppose that if Jakub adds it to the spec and to GCC, then we can
> easily update.

done.  There are now some tests for `double' recomputations, after Jakub's fix
of GCC PR debug/49846.


> Jan> +/* Allocate a copy of BLK on CU's objfile_obstack (not comp_unit_obstack),
> Jan> +   including a copy of the BLK DWARF code.  */
> Jan> +
> Jan> +static struct dwarf2_locexpr_baton *
> Jan> +dlbaton_obstack_copy (const struct dwarf_block *blk, struct dwarf2_cu *cu)
> 
> I don't understand the need for this.
> 
> Once we have mapped in a DWARF section, we do not unmap it until the
> objfile is destroyed or reloaded.  At that point, the types are all
> destroyed as well.  So, the lifetimes are already in sync, and you can
> just store a pointer directly to the DWARF data.  We already rely on
> this in many cases.

I agree, the DWARF data are no longer copied.


> Jan> +    FIELD_LOC_KIND_DWARF_BLOCK	/* dwarf_block */
> 
> Since the new data is stored as a field, it will change the Python API.
> I think there are two options:
> 
> 1. Document what the fields of a function mean.
> 2. Disallow fetching these fields in typy_fields.
> 
> I tend to prefer #2, but I can see arguments either way.

enum field_loc_kind is used only for types comparisons in gdb/python/ .
Implemented there FIELD_LOC_KIND_DWARF_BLOCK.

TYPE_CALLING_CONVENTION is not used at all in gdb/python/ so I haven't tried
to implement in gdb/python/ also TYPE_TAIL_CALL_LIST where both belong to
type_specific.func_stuff now.

I do not see how user can "fetch" the type kind in gdb/python/ , convert_field
does not access FIELD_LOC_KIND nor TYPE_FIELD_LOC_KIND in any way.


It will be in a new patchset resubmit.


Thanks,
Jan