From: Doug Evans <dje@google.com>
To: Tim Wiederhake <tim.wiederhake@intel.com>
Cc: gdb-patches@sourceware.org, palves@redhat.com,
markus.t.metzger@intel.com
Subject: Re: [PATCH v3 3/8] btrace: Use binary search to find instruction.
Date: Wed, 30 Nov 2016 23:43:00 -0000 [thread overview]
Message-ID: <f403045e318c278e3405428d463a@google.com> (raw)
Tim Wiederhake writes:
> Currently, btrace_find_insn_by_number will iterate over all function call
> segments to find the one that contains the needed instruction. This
linear
> search is too slow for the upcoming Python bindings that will use this
> function to access instructions. This patch introduces a vector in
struct
> btrace_thread_info that holds pointers to all recorded function segments
and
> allows to use binary search.
>
> The proper solution is to turn the underlying tree into a vector of
objects
> and use indices for access. This requires more work. A patch set is
> currently being worked on and will be published later.
>
> 2016-11-21 Tim Wiederhake <tim.wiederhake@intel.com>
>
> gdb/ChangeLog:
> * btrace.c (btrace_fetch): Copy function call segments pointer
> into a vector.
> (btrace_clear): Clear the vector.
> (btrace_find_insn_by_number): Use binary search to find the correct
> function call segment.
> * btrace.h (brace_fun_p): New typedef.
> (struct btrace_thread_info) <functions>: New field.
>
>
> ---
> gdb/btrace.c | 39 +++++++++++++++++++++++++++++++++------
> gdb/btrace.h | 7 +++++++
> 2 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/gdb/btrace.c b/gdb/btrace.c
> index ac7d46e..c878407 100644
> --- a/gdb/btrace.c
> +++ b/gdb/btrace.c
> @@ -1810,6 +1810,8 @@ btrace_fetch (struct thread_info *tp)
> /* Compute the trace, provided we have any. */
> if (!btrace_data_empty (&btrace))
> {
> + struct btrace_function *bfun;
> +
> /* Store the raw trace data. The stored data will be cleared in
> btrace_clear, so we always append the new trace. */
> btrace_data_append (&btinfo->data, &btrace);
> @@ -1817,6 +1819,11 @@ btrace_fetch (struct thread_info *tp)
>
> btrace_clear_history (btinfo);
> btrace_compute_ftrace (tp, &btrace);
> +
> + VEC_truncate (btrace_fun_p, btinfo->functions, 0);
> +
> + for (bfun = btinfo->begin; bfun != NULL; bfun = bfun->flow.next)
> + VEC_safe_push (btrace_fun_p, btinfo->functions, bfun);
> }
>
> do_cleanups (cleanup);
> @@ -1839,6 +1846,8 @@ btrace_clear (struct thread_info *tp)
>
> btinfo = &tp->btrace;
>
> + VEC_free (btrace_fun_p, btinfo->functions);
> +
> it = btinfo->begin;
> while (it != NULL)
> {
> @@ -2429,20 +2438,38 @@ btrace_find_insn_by_number (struct
btrace_insn_iterator *it,
> unsigned int number)
> {
> const struct btrace_function *bfun;
> + unsigned int upper, lower, average;
>
> - for (bfun = btinfo->end; bfun != NULL; bfun = bfun->flow.prev)
> - if (bfun->insn_offset <= number)
> - break;
> + if (VEC_empty (btrace_fun_p, btinfo->functions))
> + return 0;
>
> - if (bfun == NULL)
> + lower = 0;
> + bfun = VEC_index (btrace_fun_p, btinfo->functions, lower);
> + if (number < bfun->insn_offset)
> return 0;
>
> - if (bfun->insn_offset + ftrace_call_num_insn (bfun) <= number)
> + upper = VEC_length (btrace_fun_p, btinfo->functions) - 1;
> + bfun = VEC_index (btrace_fun_p, btinfo->functions, upper);
> + if (number >= bfun->insn_offset + ftrace_call_num_insn (bfun))
> return 0;
>
> + average = lower + (upper - lower) / 2;
> + bfun = VEC_index (btrace_fun_p, btinfo->functions, average);
> +
> + while ((number >= bfun->insn_offset + ftrace_call_num_insn (bfun))
> + || (number < bfun->insn_offset))
> + {
> + if (number < bfun->insn_offset)
> + upper = average - 1;
> + else
> + lower = average + 1;
> +
> + average = lower + (upper - lower) / 2;
> + bfun = VEC_index (btrace_fun_p, btinfo->functions, average);
> + }
It's a bit hard to reason about the correctness of this loop
for all edge conditions, but maybe it's just insufficient
familiarity with bfun. Ok to leave as is, just thinking
out loud.
> +
> it->function = bfun;
> it->index = number - bfun->insn_offset;
> -
> return 1;
> }
>
> diff --git a/gdb/btrace.h b/gdb/btrace.h
> index d0497b4..6de2307 100644
> --- a/gdb/btrace.h
> +++ b/gdb/btrace.h
> @@ -187,6 +187,9 @@ struct btrace_function
> btrace_function_flags flags;
> };
>
> +typedef struct btrace_function *btrace_fun_p;
> +DEF_VEC_P (btrace_fun_p);
> +
> /* A branch trace instruction iterator. */
> struct btrace_insn_iterator
> {
> @@ -337,6 +340,10 @@ struct btrace_thread_info
> struct btrace_function *begin;
> struct btrace_function *end;
>
> + /* Vector of pointer to decoded function segments. These are in
execution
> + order with the first element == BEGIN and the last element ==
END. */
> + VEC (btrace_fun_p) *functions;
> +
> /* The function level offset. When added to each function's LEVEL,
> this normalizes the function levels such that the smallest level
> becomes zero. */
> --
> 2.7.4
>
LGTM otherwise.
[with same proviso regarding others comments]
next reply other threads:[~2016-11-30 23:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-30 23:43 Doug Evans [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-11-21 15:49 [PATCH v3 0/8] Python bindings for btrace recordings Tim Wiederhake
2016-11-21 15:49 ` [PATCH v3 3/8] btrace: Use binary search to find instruction Tim Wiederhake
2016-11-29 15:47 ` 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=f403045e318c278e3405428d463a@google.com \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=markus.t.metzger@intel.com \
--cc=palves@redhat.com \
--cc=tim.wiederhake@intel.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