Re: why is gdb 5.2 so slow

[Jim Blandy <jimb@redhat.com>]

Andrew Cagney <ac131313@redhat.com> writes:
> What would really help is for the kernel to provide an option where it
> rips out out any stray breakpoints after a detach.  That way GDB could
> safely enable this by default.

I've heard it suggested that, for this behavior, the kernel shouldn't
know about breakpoints specifically, since those need all sorts of
other support (GDB has to be ptracing and waiting, etc.).  Instead,
the kernel would provide some way for a debugger to make some memory
writes (e.g., breakpoints) --- but not others (e.g., variable
modifications) --- via a special interface that would revert the
writes when the GDB process exited or died.

The ways I can think of to implement this involve page table magic,
which makes me wonder if one couldn't actually use them for per-thread
breakpoints and thread hops, too.  That is, if the debugger could make
one thread see the program text differently from the others, then it
could pull the breakpoint for that thread alone, while leaving it in
for the others.  No thread hop necessary.

I'm of out my depth here, though --- I've never looked at Linux's mm
layer, for example, and don't understand its limitations.  Just an
idea.