gdb benchmarking and profiling

gdb benchmarking and profiling

[Mickael Gicquaire]

Hi all!

i am looking for some insight on profiling gdb and gdbserver.

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.

A godd knowledge of the internals of gdb is needed and i am a newby so any
suggestion would be welcome !

Also Is gprof the obvious and only candidate ?

cheers all
mickael

-- 
---------------------------------------------------------------------------
| Mickael Gicquaire  | email mickael.gicquaire@.st.com  |                 |
|                    |                                  |   _____________ | 
| STMicroelectronics |                                  |  / ___/__   __/ |
| 1000 Aztec West    |                                  |  \__ \  /  /    | 
| Almondsbury        |   Phone 01454-462342             | /____/ /__/     |
| BRISTOL            |                                  |                 |
---------------------------------------------------------------------------

Re: gdb benchmarking and profiling

[Stan Shebs]

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

Re: gdb benchmarking and profiling

[Andrew Cagney]

> 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.


Ok.


> 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.


I don't know that bandwidth is still the most common problem (except 
where an architecture has millions of registers :-).  Rather it is 
latency.  Latency shows up in the number of round trips needed to 
achieve anything useful.  A few extra bytes here or there are in the 
noise :-)

The other is GDB's complete inability to hang onto anything when doing 
stuff like switching threads.

	Andrew

Re: gdb benchmarking and profiling

[Stan Shebs]

Andrew Cagney wrote:
> 
> I don't know that bandwidth is still the most common problem (except
> where an architecture has millions of registers :-).  Rather it is
> latency.  Latency shows up in the number of round trips needed to
> achieve anything useful.  A few extra bytes here or there are in the
> noise :-)

That's a good point - it would be very interesting to add some
machinery to monitor latency.  Collect milli/microsecond timings
just above low-level calls, accumulate the amount of time spent
waiting on turnarounds.  In fact, if you leave it in permanently
and report it to users, it would help answer the why-is-stepping-
slow-today-type questions.

Stan

Re: gdb benchmarking and profiling

[Andrew Cagney]

> 
> That's a good point - it would be very interesting to add some
> machinery to monitor latency.  Collect milli/microsecond timings
> just above low-level calls, accumulate the amount of time spent
> waiting on turnarounds.  In fact, if you leave it in permanently
> and report it to users, it would help answer the why-is-stepping-
> slow-today-type questions.


Ah, that is easy, a trawler snapped the pacific/atlantic optic fiber 
cable (again) and the real world has been reduced to using carrier pigeons.

	Andrew