This is the mail archive of the
mailing list for the GDB project.
Toward multicore GDB - Target agent
- From: Stan Shebs <stanshebs at earthlink dot net>
- To: gdb at sourceware dot org
- Date: Tue, 01 Nov 2011 17:15:51 -0700
- Subject: Toward multicore GDB - Target agent
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
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.