Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <alves.ped@gmail.com>
To: Pedro Alves <palves@redhat.com>
Cc: markus.t.metzger@intel.com, gdb-patches@sourceware.org,
	 markus.t.metzger@gmail.com, jan.kratochvil@redhat.com,
	 tromey@redhat.com, kettenis@gnu.org
Subject: Re: [patch v4 02/13] thread, btrace: add generic branch trace support
Date: Tue, 27 Nov 2012 18:38:00 -0000	[thread overview]
Message-ID: <50B508A1.9090800@gmail.com> (raw)
In-Reply-To: <50B5072E.4070709@redhat.com>

On 11/27/2012 06:32 PM, Pedro Alves wrote:
> My main comment for this patch is that btrace.h or btrace-common.h lack a
> general overview of what branch tracing is, and the role of the data structures.
> 
>> +
>> +/* Disable branch tracing for @tp. Ignore errors.  */
> 
> "@tp" is not the standard GNU way to refer to arguments.
> Write "TP".  Always double-space after period that ends sentence.
> 
>> +static int
>> +do_disconnect_btrace (struct thread_info *tp, void *ignored)
> 
> 
>> +  /* When killing the inferior, we may have lost our target before we disable
>> +     branch tracing.  */
> 
> Hmm, how does that happen?  Can you explain better?
> 
>> +  if (target_supports_btrace ())
>> +    target_disable_btrace (btp->target);
> 
> 
>> +/* Disable branch tracing for @tp. Ignore errors.  */
>> +static int
>> +do_disconnect_btrace (struct thread_info *tp, void *ignored)
>> +{
>> +  if (tp->btrace.target)
>> +    {
>> +      volatile struct gdb_exception error;
>> +
>> +      TRY_CATCH (error, RETURN_MASK_ERROR)
>> +	disable_btrace (tp);
>> +    }
>> +
>> +  return 0;
>> +}
>> +
> 
> Likewise, what kind of errors are expected here?
> 
> 
> 
> +/* Functions to iterate over a thread's branch trace.
> +   There is one global iterator per thread.  The iterator is reset implicitly
> +   when branch trace for this thread changes.
> +   On success, read_btrace sets the iterator to the returned trace entry.
> +   Returns the selected block or NULL if there is no trace or the iteratoris
> +   out of bounds.  */
> +extern struct btrace_block *read_btrace (struct thread_info *, int);
> +extern struct btrace_block *prev_btrace (struct thread_info *);
> +extern struct btrace_block *next_btrace (struct thread_info *);
> 
> Typo "iteratoris".  Why is there an iterator per thread?  I realize
> later patches may make that clearer, but from reading this code, it's
> natural do draw a parallel to "selected frame", and in that case, you
> don't have one per-thread.
> 
> 
>> +/* Return the current branch trace vector for a thread, or NULL if ther is no
>> +   trace.  */
>> +extern VEC (btrace_block_s) *get_btrace (struct thread_info *);
> 
> Typo "there".
> 
>> /* See btrace.h.  */
>> void
> 
> Space between comment and function start.
> 
>> disable_btrace (struct thread_info *tp)
>> {
>>   struct btrace_thread_info *btp = &tp->btrace;
>>   int errcode = 0;
>>
>>   if (!btp->target)
>>     error (_("Branch tracing not enabled for %s."),
>> 	   target_pid_to_str (tp->ptid));
> 
> No sure these errors are a good idea.  Might be better to make
> them idempotent.  So that e.g., "thread apply all btrace"
> 
>>
>>   /* When killing the inferior, we may have lost our target before we disable
>>      branch tracing.  */
>>   if (target_supports_btrace ())
>>     target_disable_btrace (btp->target);
>>
>>   btp->target = NULL;
>>   VEC_free (btrace_block_s, btp->btrace);
>> }
> 
> 
> 
> 
>> /* Update @btp's trace data in case of new trace.  */
>> static void
>> update_btrace (struct btrace_thread_info *btp)
>> {
>>   if (btp->target && target_btrace_has_changed (btp->target))
> 
> (Personally, I very much dislike pointer->boolean implicit conversions.)
> 
> 
>>     {
>>       btp->btrace = target_read_btrace (btp->target);
>>       btp->iterator = -1;
>>
>>       /* The first block ends at the current pc.  */
>>       if (!VEC_empty (btrace_block_s, btp->btrace))
>> 	{
>> 	  struct frame_info *frame = get_current_frame ();
> 
> This get_current_frame call here looks fishy.  This function takes a
> btrace_thread_info, and its callers work with a thread_info directly,
> which indicates that they may work with some current thread other than
> the thread passed in as argument.
> 
>>
>> 	  if (frame)
>> 	    {
> 
> What's this check supposed to mean?  get_current_frame never
> returns NULL.
> 
>> 	      struct btrace_block *head =
>> 		VEC_index (btrace_block_s, btp->btrace, 0);
> 

> = goes at the start of the next line.  Other instances of this in the
> patch (and probably the series).
> 
>>
>> 	      if (head && !head->end)
>> 		head->end = get_frame_pc (frame);

I meant to suggest bypassing frames, and using regcache_read_pc instead.

>> 	    }
>> 	}
>>     }
>> }
> 
> 
>> +/* See btrace.h.  */
>> +struct btrace_block *
>> +read_btrace (struct thread_info *tp, int index)
>> +{
>> +  struct btrace_thread_info *btp = &tp->btrace;
>> +
>> +  if (index < 0)
>> +    error (_("Invalid index: %d."), index);
> 
> Can this happen normally, or should this be an assertion/internal
> error?
> 
> 
> 
> 
> --- a/gdb/target.c
> +++ b/gdb/target.c
> @@ -701,6 +701,11 @@ update_current_target (void)
>        INHERIT (to_traceframe_info, t);
>        INHERIT (to_use_agent, t);
>        INHERIT (to_can_use_agent, t);
> +      INHERIT (to_supports_btrace, t);
> +      INHERIT (to_enable_btrace, t);
> +      INHERIT (to_disable_btrace, t);
> +      INHERIT (to_btrace_has_changed, t);
> +      INHERIT (to_read_btrace, t);
>        INHERIT (to_magic, t);
>        INHERIT (to_supports_evaluation_of_breakpoint_conditions, t);
>        INHERIT (to_can_run_breakpoint_commands, t);
> @@ -943,6 +948,21 @@ update_current_target (void)
>  	    (int (*) (void))
>  	    return_zero);
>    de_fault (to_execution_direction, default_execution_direction);
> +  de_fault (to_supports_btrace,
> +	    (int (*) (void))
> +	    return_zero);
> +  de_fault (to_enable_btrace,
> +	    (struct btrace_target_info * (*) (ptid_t))
> +	    tcomplain);
> +  de_fault (to_disable_btrace,
> +      (void (*) (struct btrace_target_info *))
> +	    tcomplain);
> +  de_fault (to_btrace_has_changed,
> +      (int (*) (struct btrace_target_info *))
> +	    tcomplain);
> +  de_fault (to_read_btrace,
> +      (VEC (btrace_block_s) * (*) (struct btrace_target_info *))
> +	    tcomplain);
> 
>  #undef de_fault
> 
> @@ -4149,6 +4169,75 @@ target_ranged_break_num_registers (void)
>    return -1;
>  }
> 
> +/* See target.h.  */
> +int
> +target_supports_btrace (void)
> +{
> +  struct target_ops *t;
> +
> +  for (t = current_target.beneath; t != NULL; t = t->beneath)
> +    if (t->to_supports_btrace != NULL)
> +      return t->to_supports_btrace ();
> +
> +  return 0;
> +}
> 
> You either implement target_supports_btrace like this, doing the
> explicit walk, or use the INHERIT/de_fault mechanism, and define
> target_supports_btrace as macro that calls
> current_target.to_supports_btrace.  Never both ways at the
> same time.
> 


-- 
Pedro Alves


  reply	other threads:[~2012-11-27 18:38 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-27 10:50 [patch v4 00/13] branch tracing support for Atom markus.t.metzger
2012-11-27 10:49 ` [patch v4 01/13] disas: add precise instructions flag markus.t.metzger
2012-11-27 16:49   ` Pedro Alves
2012-11-27 16:52     ` Jan Kratochvil
2012-11-27 16:56       ` Pedro Alves
2012-11-27 17:26     ` Metzger, Markus T
2012-11-27 17:33       ` Pedro Alves
2012-11-28 14:44         ` Metzger, Markus T
2012-11-27 10:49 ` [patch v4 03/13] cli, btrace: add btrace cli markus.t.metzger
2012-11-27 21:53   ` Tom Tromey
2012-11-30 15:09     ` Metzger, Markus T
2012-11-30 15:16       ` Jan Kratochvil
2012-11-30 15:23         ` Metzger, Markus T
2012-11-27 10:50 ` [patch v4 09/13] gdbserver, btrace: add generic btrace support markus.t.metzger
2012-11-28 20:32   ` Pedro Alves
2012-12-04 14:50     ` Metzger, Markus T
2012-11-27 10:50 ` [patch v4 05/13] linux, btrace: perf_event based branch tracing markus.t.metzger
2012-11-28 17:31   ` Pedro Alves
2012-12-03 14:38     ` Metzger, Markus T
2012-11-27 10:50 ` [patch v4 11/13] test, btrace: add branch tracing tests markus.t.metzger
2012-11-27 10:50 ` [patch v4 10/13] gdbserver, linux, btrace: add btrace support for linux-low markus.t.metzger
2012-11-28 20:44   ` Pedro Alves
2012-12-05  9:27     ` Metzger, Markus T
2012-11-27 10:50 ` [patch v4 02/13] thread, btrace: add generic branch trace support markus.t.metzger
2012-11-27 18:32   ` Pedro Alves
2012-11-27 18:38     ` Pedro Alves [this message]
2012-11-28  0:41       ` Pedro Alves
2012-11-29 16:39     ` Metzger, Markus T
2012-11-27 10:50 ` [patch v4 06/13] linux, i386, amd64: enable btrace for 32bit and 64bit linux native markus.t.metzger
2012-11-28 18:40   ` Pedro Alves
2012-12-03 16:24     ` Metzger, Markus T
2012-11-27 10:50 ` [patch v4 08/13] remote, btrace: add branch trace remote ops markus.t.metzger
2012-11-28 19:23   ` Pedro Alves
2012-12-04 12:47     ` Metzger, Markus T
2012-11-27 10:50 ` [patch v4 13/13] btrace, x86: restrict to Atom markus.t.metzger
2012-11-27 11:19   ` Mark Kettenis
2012-11-27 11:49     ` Metzger, Markus T
2012-11-27 14:42       ` Mark Kettenis
2012-11-27 15:14         ` Metzger, Markus T
2012-11-27 15:32           ` Pedro Alves
2012-11-27 13:05   ` Jan Kratochvil
2012-11-27 14:04     ` Metzger, Markus T
2012-11-27 14:29       ` Jan Kratochvil
2012-11-27 15:14         ` Metzger, Markus T
2012-11-27 15:50           ` Pedro Alves
2012-11-27 15:54             ` Metzger, Markus T
2012-12-06 10:15         ` Metzger, Markus T
2012-11-27 10:50 ` [patch v4 07/13] xml, btrace: define btrace xml document style markus.t.metzger
2012-11-28 18:53   ` Pedro Alves
2012-12-04 10:35     ` Metzger, Markus T
2012-11-27 10:50 ` [patch v4 04/13] configure: add check for perf_event header markus.t.metzger
2012-11-28 10:11   ` Pedro Alves
2012-11-28 14:52     ` Metzger, Markus T
2012-11-28 14:55       ` Pedro Alves
2012-11-27 10:50 ` [patch v4 12/13] test, btrace: more branch tracing tests markus.t.metzger
2012-11-27 13:11 ` [patch v4 00/13] branch tracing support for Atom Jan Kratochvil
2012-11-27 14:26   ` Metzger, Markus T
2012-11-27 14:32     ` Jan Kratochvil
2012-11-27 14:40       ` Metzger, Markus T
2012-11-27 15:36       ` Jan Kratochvil
2012-11-27 16:17         ` Metzger, Markus T
2012-11-27 16:28           ` Jan Kratochvil
2012-11-27 17:30             ` Metzger, Markus T
2012-11-27 18:31               ` Jan Kratochvil
2012-11-27 18:56                 ` Markus Metzger
2012-11-28 19:01                   ` Jan Kratochvil
2012-11-29  9:13                     ` Metzger, Markus T

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=50B508A1.9090800@gmail.com \
    --to=alves.ped@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=kettenis@gnu.org \
    --cc=markus.t.metzger@gmail.com \
    --cc=markus.t.metzger@intel.com \
    --cc=palves@redhat.com \
    --cc=tromey@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