This is the mail archive of the gdb@sources.redhat.com 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]

Re: gdb benchmarking and profiling


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


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