why is gdb 5.2 so slow

[Andrew Cagney]

>> - Removing all breakpoints, that's just wrong, there's a test in
>> signals.exp (xfailed :P) which shows why.  We should _only_ be
> 
> removing
> 
>> any breakpoints at the address we're hopping over.
> 
> [DPH] I thought we need this to show a clean program space, i.e. without
> 
> 	gdb's modifications, i.e. breakpoints. My guess is that the code
> is
> 	general that does this and we'd have to put more logic in to
> detect 
> 	when we are poking in the address space after the breakpoint.

No.

Breakpoints are pulled to ensure that the target is clean when [not if 
:-)] gdb barfs / is killed / ....  Attach GDB to a process, set a few 
breakpoints, continue the process, and then shoot GDB.  The process 
quickly dies with a SIGTRAP from one of those, still in memory, breakpoints.

GDB does have methods that present a clean program space.   Using those 
functions, and not pulling breakpoints, should largely involve legwork. 
  However, things like single-step and thread-hop would be more 
complicated involving a bit of think-o to get right.

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.

Andrew