From: Stan Shebs <shebs@apple.com>
To: Mickael Gicquaire <Mickael.Gicquaire@st.com>
Cc: "gdb@sources.redhat.com" <gdb@sources.redhat.com>
Subject: Re: gdb benchmarking and profiling
Date: Wed, 08 Aug 2001 10:46:00 -0000 [thread overview]
Message-ID: <3B717B0D.CD7CF49E@apple.com> (raw)
In-Reply-To: <1010808103350.ZM10068@bristol.st.com>
Mickael Gicquaire wrote:
>
> i am looking for some insight on profiling gdb and gdbserver.
gprof is pretty much all there is.
> I was wondering if someone had some insight on the matter especially concerning
> some kind of benchmarks. What i want to achieve is to have a good knowlegde of
> where gdb and gdb server spend its time depending on the type of program that
> is being debugged.
In my view (which may be out of date), there are two key areas to
look at when considering GDB performance. The first is symbol
reading. Believe it or not, this is almost always a CPU-bound
activity - BFD doesn't take very long to read even large chunks
of debug info, and the rest of the time is spent turning the raw
info into GDB symbolic info. Thus partial symbol tables for
instance, the theory being that you're usually not interested in
a function's local variables until you've actually stopped in
that function. gprof profiling works well for studying this,
just run in batch mode.
The second area is the efficiency of the debug protocol. This
is ultra-critical for remote debugging over serial lines, but
still matters even for native ptrace debugging. The game here
is to count the bytes going back and forth, and the number of
interchanges (or context switchesa) between GDB and the inferior.
For instance, sometimes GDB needs to analyze a function's
prologue in order to determine where the arguments are stored,
so it knows how to do a backtrace. It would be very inefficient
to pull the function's instructions from the target, since (usually)
the same instructions are readily available in the executable.
Another example that was touched on recently was the size of
memory reads - GDB tends to read whole words, even if it only
needs a single byte. (Of course, if the word is cached once
read, then the next byte is readily available.) There are all
kinds of opportunities to make GDB interact with the target
more efficiently, just start studying the packets; "set targetdebug"
is helpful to get started.
Stan
next prev parent reply other threads:[~2001-08-08 10:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-08 2:33 Mickael Gicquaire
2001-08-08 10:46 ` Stan Shebs [this message]
2001-08-09 12:13 ` Andrew Cagney
2001-08-09 12:30 ` Stan Shebs
2001-08-09 12:40 ` Andrew Cagney
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=3B717B0D.CD7CF49E@apple.com \
--to=shebs@apple.com \
--cc=Mickael.Gicquaire@st.com \
--cc=gdb@sources.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