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

[Tom Tromey]

>>>>> "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.

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.

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.

Jan> @@ -12624,6 +12844,8 @@ dwarf_tag_name (unsigned tag)
Jan>        return "DW_TAG_PGI_kanji_type";
Jan>      case DW_TAG_PGI_interface_block:
Jan>        return "DW_TAG_PGI_interface_block";
Jan> +    case DW_TAG_GNU_call_site:
Jan> +      return "DW_TAG_GNU_call_site";

Thanks.

I wish this were more automatic; and done in one spot so we don't
constantly have to update both binutils and gdb for this kind of change.

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.

Tom