This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH 05/11] btrace: Use function segment index in insn iterator.


> -----Original Message-----
> From: Wiederhake, Tim
> Sent: Friday, February 17, 2017 2:26 PM
> To: gdb-patches@sourceware.org
> Cc: Metzger, Markus T <markus.t.metzger@intel.com>
> Subject: [PATCH 05/11] btrace: Use function segment index in insn iterator.

Hello Tim,

 
> 2017-02-17  Tim Wiederhake  <tim.wiederhake@intel.com>
> 
> gdb/ChangeLog
> 	* btrace.c: (btrace_insn_get, btrace_insn_get_error,
> btrace_insn_number,
> 	btrace_insn_begin, btrace_insn_end, btrace_insn_next,
> btrace_insn_prev,
> 	btrace_find_insn_by_number): Replaced function segment pointer with
> 	index.

I think this is "Replace function segment ...".  More below.


> diff --git a/gdb/btrace.c b/gdb/btrace.c
> index 31590ce..1e110cc 100644
> --- a/gdb/btrace.c
> +++ b/gdb/btrace.c
> @@ -2236,8 +2236,8 @@ btrace_insn_get (const struct btrace_insn_iterator *it)
>    const struct btrace_function *bfun;
>    unsigned int index, end;
> 
> -  index = it->index;
> -  bfun = it->function;
> +  index = it->insn_index;
> +  bfun = VEC_index (btrace_fun_p, it->btinfo->functions, it->call_index);

Should we assert that IT->CALL_INDEX lies inside the vector's bounds?  More below.


> diff --git a/gdb/btrace.h b/gdb/btrace.h
> index c49b114..53df6e9 100644
> --- a/gdb/btrace.h
> +++ b/gdb/btrace.h
> @@ -196,12 +196,12 @@ struct btrace_insn_iterator
>    /* The branch trace information for this thread.  Will never be NULL.  */
>    const struct btrace_thread_info *btinfo;
> 
> -  /* The branch trace function segment containing the instruction.
> -     Will never be NULL.  */
> -  const struct btrace_function *function;
> +  /* The index of the function call segment in struct btrace_thread_info's
> +     FUNCTIONS vector.  Note that index + 1 == number.  */
> +  unsigned int call_index;

The comment is really referring to the iterator's BTINFO field, isn't it?  Why
not say "The index in BTINFO->FUNCTIONS".  I don't think we need the note
on how the index relates to the function number, here.

With this change, the btrace_insn_iterator really contains all the fields of
btrace_call_iterator.  Should we make it actually contain a btrace_call_iterator?

It might simplify the above code in that it allows us to use btrace_call_get instead
of accessing the BTINFO->FUNCTIONS vector directly.


> @@ -1692,7 +1692,8 @@ record_btrace_frame_sniffer (const struct
> frame_unwind *self,
> 
>        replay = tp->btrace.replay;
>        if (replay != NULL)
> -	bfun = replay->function;
> +	bfun = VEC_index (btrace_fun_p, tp->btrace.functions,
> +			  replay->call_index);

We should use REPLAY->BTINFO or, even better, btrace_call_get.


> @@ -2705,7 +2706,7 @@ record_btrace_set_replay (struct thread_info *tp,
> 
>    btinfo = &tp->btrace;
> 
> -  if (it == NULL || it->function == NULL)
> +  if (it == NULL)
>      record_btrace_stop_replaying (tp);

IT->FUNCTION == NULL checks for the end iterator.  I don't think that we can
simply omit it.

Thanks,
Markus.

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]