From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: Mickael Gicquaire Cc: "gdb@sources.redhat.com" Subject: Re: gdb benchmarking and profiling Date: Wed, 08 Aug 2001 10:46:00 -0000 Message-id: <3B717B0D.CD7CF49E@apple.com> References: <1010808103350.ZM10068@bristol.st.com> X-SW-Source: 2001-08/msg00075.html 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