Re: why is gdb 5.2 so slow

Andrew Cagney
2002-11-01T20:46:22Z

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