This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: why is gdb 5.2 so slow



[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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]