This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 02/12] entryval: Basic parameter values recovery
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