why is gdb 5.2 so slow

[Andrew Cagney]

>> [my guess] If the condition fails, we need to thread-hop.  If the 
>> condition succeeds we need to stop all threads anyway.
> 
> 
> Oh, blast it.  So we can't use this for general conditional
> breakpoints.  If the condition is true we stop all threads before
> giving a prompt; if the condition is false we stop all threads in order
> to step over the breakpoint.

Well, the conditional expression could be pushed down into the target 
(aka kernel) as byte codes.  Part of that introspect stuff.  That way 
the kernel could co-ordinate it.

> We could do thread-specific breakpoints hit by the wrong thread this
> way... and thread-specific conditional breakpoints hit by the right
> thread but with the condition false could _probably_ be done this way
> but implementing it would be complicated.

But GDB needs to do thread specific breakpoints anyway :-)

> Now, thread-specific breakpoints hit by the wrong thread could be used
> to speed up "next"/software-single-step...
> 

>> Uli (glibc), KevinB, MichaelS, and I happened to be in the same room and 
>> talked about this.  /procfs was suggested as an alternative path.  For 
>> ptrace() Uli indicated something about running out of register arguments 
>> to use across a system call.
> 
> 
> I don't know what he's referring to... wait... request, pid, len,
> target address, buffer.  x86 can only do four.  Crappy but it could be
> worked around.
> 
> In any case, this reminded me of something I keep forgetting.  Modern
> kernels a ptrace-attached process can open the child's /proc/<pid>/mem
> and read from it.  Writing to it is disabled, and mmap is not
> implemented (oh the violence to the mm layer if that was allowed!). 
> But reading from it is probably faster than PTRACE_PEEKTEXT.  I'll
> investigate.

Ah.  How does solaris work then?

>> Apparently that guarentee is comming.  Solaris, for instance, is moving 
>> back to 1:1.  My instinct is that reduceing the system calls will make a 
>> far greater improvement than trimming back glibc.
> 
> 
> Well, I'd hate to lose NGPT support; like it or not a lot of people
> (especially in the carrier-grade

Bingo!

>   space) are starting to use it.  At the
> same time we don't need to be using the heavyweight interface when it
> isn't needed.

(By NGPT I'm guessing that you mean N:M threads) I don't think GDB will 
loose that - it will always need to support things like N:1.  It's just 
that for 1:1 threads, the implementation can be shaved down to nothing.

Andrew