A while back, CodeSourcery (now part of Mentor Graphics) did a project 
to implement "global breakpoints" for GDB.  A global breakpoint applies 
to multiple processes, both current and future.  The idea is that one 
might have an application that is an assembly of similar processes 
(perhaps running in parallel on a multicore system), or want to break on 
a shared library function when it is first called, irrespective of which 
process calls it first.  In GDB it is specified as an addition to the 
breakpoint command - "break pow process *" will catch calls to pow() for 
instance.

One way this might be made to work is to somehow make a GDB the parent 
of all other processes, then it gets a chance to monitor each process as 
it starts up.  This is unusably inefficient; we really just need the 
breakpoint trap to be inserted at process startup and then let things 
run quietly until the trap is hit, at that point requesting the GDB user 
whether to attach to the process, or let it continue.

The code I've included here is an implementation of that scheme.  It is 
a kernel module that keeps a list of processes in which breakpoints have 
been inserted, and a list of clients (GDB, LLDB, etc) to inform about 
hits.  The interface is via /dev/breakpoint, which takes commands issued 
by a suitably-modified GDB (the GDB patches are available at 
http://sourceware.org/ml/gdb-patches/2011-06/msg00163.html).  It uses 
kprobes to hook into the relevant parts of the process and 
memory-mapping subsystems.  It's not especially complicated, the module 
consisting of just the one attached source file.

The question at hand is: what to do with this thing?  Several people 
have expressed interest in the concept, but it pushes the envelope of 
what the debugger normally does, which is to control a single process 
and its children.  It's a little freaky, though not unheard-of, to have 
a debugging agent running inside the kernel; one could argue that it's 
the kind of development support hook that *should* be in the kernel.  
It's certainly of more interest for high-performance and multi-core 
embedded systems, where the developer reasonably expects to have control 
over all the processes on the target, than for desktops, where one is 
going to be firewalled against setting breakpoints in other people's 
processes.

Any and all comments appreciated! (even "this is a stupid idea" 
reactions :-) )

Stan Shebs
stan@codesourcery.com