Toward multicore GDB - Target agent

[Stan Shebs <stanshebs@earthlink.net>]

A second major issue to be addressed for multicore GDB is performance.

The traditional debugging model is conceptually low-speed - using a 
combination of breakpoints and stepping, we force the program to run no 
faster than our own thought process, so we can compare what the program 
is doing with our mental model of what should be happening.

This is a good thing, and it's best to always have low-speed operation 
as an option.

But then what about bugs that only manifest themselves at full speed?  
Thread races for example.  If single-stepping, the chance is likely to 
be vanishingly small that two threads access the same unprotected data 
simultaneously.  But continue instead of step, or have two cores each 
running a thread, and the bug quickly reappears.

A problem, then, with GDB debugging a many-core program is that it will 
interfere too much with program execution and needs to back off.  But 
then how does one debug without having the debugger in the middle of 
every operation?

Tracepoints hint at the answer.  They work by handling debugger-type 
operations at the target, without direct involvement by GDB.  In the 
extreme case of fast tracepoints, the debugging operations are handled 
by a jump out and back, so not even a context switch occurs; a 
conditional can be tested in nanoseconds instead of microseconds or worse.

So we propose to improve multicore debug performance by growing the 
tracepoint agent into a general debugging agent, and structuring it as a 
dynamically-loaded library.  As this agent need not be specific to GDB 
(or GDBserver), we are tentatively calling it the Common Agent Library, 
and giving it an LGPL license.

The agent library is in some ways similar to a stub, but is not itself a 
stub, and could be used even in a native debugging situation.  Its main 
purpose is to try to handle debugging activities locally, only getting 
GDB involved in exceptional cases.

For instance, the agent library will have a version of the agent 
expression bytecode interpreter, but will be able to use it to test 
conditionals for breakpoints as well as tracepoints, and so if possible 
(for instance, no testing against convenience variables), GDB can 
download the conditional and only be notified of a stop when the 
conditional evaluates to true.

Even better, we can extend this to ptc sets.  Then the user can set a 
breakpoint to trigger on a subset of threads, but there is no 
communication overhead until one of the intended threads hits the 
breakpoint.  It could even be that the agent could accumulate all the 
stops in a short time window, and report them as a group, although I 
think that is too ambitious for an initial version.

The exact API of the agent library is yet to be defined, and there are 
plenty of details to be worked out, so I invite people to weigh in with 
their ideas.  We have a fair amount of freedom to come up with good 
designs, but we do have to produce a working library within a few 
months, leaving room to extend as we develop experience with it.

Stan
stan@codesourcery.com