This is the mail archive of the 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]
Other format: [Raw text]

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


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