Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Stan Shebs <stan@codesourcery.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Handle LOC_COMPUTED variables in tracepoint actions
Date: Fri, 18 Dec 2009 20:21:00 -0000	[thread overview]
Message-ID: <m3eimsf2yu.fsf@fleche.redhat.com> (raw)
In-Reply-To: <4B2BDC02.9010209@codesourcery.com> (Stan Shebs's message of 	"Fri, 18 Dec 2009 11:46:10 -0800")

>>>>> "Stan" == Stan Shebs <stan@codesourcery.com> writes:

Stan> The last time that anybody used tracepoints much, stabs was still
Stan> the norm and Dwarf 2 the newbie, and so nobody thought much about
Stan> handling variables with computed locations.

Stan> This patch doesn't handle every possible computed location, that's
Stan> a big project of its own (basically translating arbitrary dwarf2
Stan> bytecode sequences into equivalent agent expression bytecodes)

Fun project :-).  Let me suggest a feature request for this in
bugzilla...

Stan> Even the simplified version is a little arcane, so I'll leave it
Stan> up for comments for a few days before committing.

This patch looks pretty good to me.

Does this handle DW_OP_call_frame_cfa?  I didn't see any explicit
support for it, but I could be missing something.  IIUC, recent versions
of gcc tend to emit this for all local variables.

I also have a couple tiny nits to pick.
  
Stan> + struct agent_expr *
Stan> + gen_trace_for_var (CORE_ADDR scope, struct symbol *var)

Intro comment.

Stan> + static void
Stan> + dwarf_expr_frame_base_1 (struct symbol *framefunc, CORE_ADDR pc,
Stan> + 			 gdb_byte **start, size_t * length);

Extra space before "length".  This occurs twice.

Stan> + 	  /* We don't know what to do with the frame base expression,
Stan> + 	     so we can't trace this variable; give up.  */
Stan> + 	  error (_("Cannot generate expression to collect symbol \"%s\"."),
Stan> + 		 SYMBOL_PRINT_NAME (symbol));

As a user I would appreciate it if this error told me more about what
was wrong.  Like, maybe it could mention that the DWARF expression is
too complicated, or maybe ask me to file a bug report.

Tom


  reply	other threads:[~2009-12-18 20:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18 19:46 Stan Shebs
2009-12-18 20:21 ` Tom Tromey [this message]
2009-12-23 23:16   ` Stan Shebs

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=m3eimsf2yu.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=stan@codesourcery.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