From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Gary Benson <gbenson@redhat.com>
Subject: Re: [RFA] Improve performance with lots of shared libraries
Date: Fri, 01 Jul 2011 17:57:00 -0000 [thread overview]
Message-ID: <201107011856.56157.pedro@codesourcery.com> (raw)
In-Reply-To: <201107011845.01404.pedro@codesourcery.com>
On Friday 01 July 2011 18:45:01, Pedro Alves wrote:
> I'd rather a split in two different chunks/concepts, as per
> your description of the problem:
>
> 1 - find_pc_partial_function is expensive, and as such we should
> only call it when necessary. Can we somehow only do this:
>
> > /* Don't care about return value; stop_func_start and stop_func_name
> > will both be 0 if it doesn't work. */
> > find_pc_partial_function (stop_pc, &ecs->stop_func_name,
> > &ecs->stop_func_start, &ecs->stop_func_end);
> > ecs->stop_func_start
> > += gdbarch_deprecated_function_start_offset (gdbarch);
>
> bit when necessary, rather than listing some special
> cases when it is not necessary? That is, make that bit
> a bit more lazy. E.g, it looks like stops for
> BPSTAT_WHAT_STOP* never need that info. (beware of places
> that pass the ecs down as argument to some function that
> ends up using those fields).
Reading back, I may have not been clear --- I'm not asking
to come up with conditions to whitelist these call under,
but rather to move that bit to a new function, like:
static void
stop_func_info (struct execution_control_state *ecs)
{
/* Don't care about return value; stop_func_start and stop_func_name
will both be 0 if it doesn't work. */
find_pc_partial_function (stop_pc, &ecs->stop_func_name,
&ecs->stop_func_start, &ecs->stop_func_end);
ecs->stop_func_start
+= gdbarch_deprecated_function_start_offset (gdbarch);
}
and then call that function a bit further down, e.g.,
in the BPSTAT_WHAT_STEP_RESUME case; where it reads:
/* When stepping backward, stop at beginning of line range
(unless it's the function entry point, in which case
keep going back to the call point). */
where it reads "Check for subroutine calls.", etc.
--
Pedro Alves
next prev parent reply other threads:[~2011-07-01 17:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-01 16:51 Gary Benson
2011-07-01 17:19 ` Tom Tromey
2011-07-04 14:10 ` Gary Benson
2011-07-01 17:32 ` Joel Brobecker
2011-07-04 14:21 ` Gary Benson
2011-07-01 17:45 ` Pedro Alves
2011-07-01 17:57 ` Pedro Alves [this message]
2011-09-09 14:25 Gary Benson
2011-09-09 14:35 ` Daniel Jacobowitz
2011-09-09 14:51 ` Jan Kratochvil
2011-09-09 15:04 ` Pedro Alves
2011-09-09 19:41 ` Jan Kratochvil
2011-09-12 12:44 ` Pedro Alves
2011-09-12 16:44 ` Jan Kratochvil
2011-09-14 9:28 ` Gary Benson
2011-10-04 19:46 ` Tom Tromey
2011-09-09 15:11 ` Pedro Alves
2011-09-09 14:53 ` Jan Kratochvil
2011-10-04 20:03 ` Tom Tromey
2011-09-22 17:35 Gary Benson
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=201107011856.56157.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gbenson@redhat.com \
--cc=gdb-patches@sourceware.org \
/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