Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch 02/12] entryval: Basic parameter values recovery
Date: Tue, 19 Jul 2011 14:43:00 -0000	[thread overview]
Message-ID: <m3pql65p63.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20110718201528.GC30496@host1.jankratochvil.net> (Jan	Kratochvil's message of "Mon, 18 Jul 2011 22:15:28 +0200")

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


  reply	other threads:[~2011-07-19 14:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-18 20:17 Jan Kratochvil
2011-07-19 14:43 ` Tom Tromey [this message]
2011-07-24 18:10   ` [patch] Remove excessive DWARF block xmemdup by me [Re: [patch 02/12] entryval: Basic parameter values recovery] Jan Kratochvil
2011-09-13 21:53     ` [patch] Remove excessive DWARF block xmemdup by me Jan Kratochvil
2011-07-29 15:35   ` [patch 02/12] entryval: Basic parameter values recovery Jan Kratochvil
2011-07-29 16:08     ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3pql65p63.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox