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]

[PATCH 0/2] Global breakpoints, introduction

This pair of patches plus Linux kernel module adds global breakpoints to GDB. Global breakpoints are installed in multiple processes of a target, *including* processes not under GDB control, and processes not yet created. Conceptually, it's similar to breakpoints in some RTOSes where tasks share all or part of an address space, and so a breakpoint in the shared space will hit in whatever task reaches it first.

In Linux, this is a little more complicated. We don't want to force every process to run under the debugger all the time, and we need to catch new processes somehow. The implementation here uses a kernel module that communicates with debuggers via a device /dev/breakpoint. In the absence of appropriate internal support in Linux, the module uses kprobes to hook into several key spots, and then installs and manages breakpoint traps on behalf of the debugger. When one of these traps is hit, the device removes the trap and notifies GDB, which then attaches to the process and installs its own breakpoint trap in the usual way.

The user interface adds a "process" keyword to breakpoints, along the lines of "thread", so for instance "break mysubr process *" installs a breakpoint in all processes using the file in which mysubr is defined (which could be either the exec file or a shared library). "break mysubr process future" installs only in processes created after the breakpoint is defined. In addition, combinations and process user/owner qualifications are possible, so you can do instant system catatonia with something ill-advised like "break malloc process all/root". :-)

The patch here includes both native Linux and remote protocol for Linux gdbserver, and I've attached a tgz of the (small) kernel module sources to this message. (The module has only been tested much on the 2.6.35 kernel.)

This is kind of a freaky addition - it's very cool to see in action, as you can catch the first process to call some library function, and it will be even more interesting for multicore situations where lots of copies of a exec may be running. At the same time, it pushes the envelope on hooking into the system, and in the absence of full multi-process infrastructure, the user interface is a little hacky. So I'm open to ideas on how to do all this better.


Attachment: bpmodule.tgz
Description: GNU Zip compressed data

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