This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: Proof-of-concept on fd-connected linux-nat.c server
On Sun, 10 May 2009 12:25:24 +0200, Pedro Alves wrote:
> You're reinventing a remote protocol, and, at the wrong layer, IMO.
I cannot say too much about the gdbserver layer placement but thanks for the
confirmation about gdbserver.
> The single most important time sensitive operation when debugging is
> single-stepping speed, and that's mostly dominated by roundtrips.
>
> > What do you think about implementing gdbserver.ko?
>
> What would this be solving?
ptrace interface is wrong: Its binding on waitpid()/SIGCHLD/SIGSTOP is
a nightmare conflicting with regular uses of waitpid/SIGCHLD/SIGSTOP. Also
its TID vs. PID handling is not right, just attaching to a whole process is
a task for many screens of code in GDB.
One feature of dropping ptrace() is to make "step" faster. While there exists
now PTRACE_SINGLEBLOCK==DEBUGCTLMSR_BTF still the kernel can perform
"step/"next" faster without the userland/kernelland switching, even for an
inferior code loop on a single line of code (we want to step over).
PTRACE_SYSCALL is too general, it should be possible to stop for example only
when inferior calls a syscall related to the specified file descriptor(s).
PTRACE_O_TRACE{FORK,VFORK,CLONE} works but it is a nightmare with new child
tasks appearing before the original call reports the new task TID.
Also kernel (already?) contains debugging infrastructure for systemtap such as
for placing/stepping-over breakpoints which can be reused by GDB if those
GDB parts get appropriately disabled on the enhanced kernels.
(As i do not work on this project I may not know it all.)
> In all seriousness, I think that you're going the wrong direction
> entirely.
Just to make it clear - my patch was just the "proof-of-concept", nothing
I would ever want to get accepted anywhere.
Still it is not clear to me if gdbserver.ko is the right way to get rid of the
ptrace/waitpid/SIGCHLD/SIGSTOP pain.
> I really suggest you get acquainted with the remote
> protocol and gdbserver, before coming up with a new solution.
May I ask why do you put effort both on linux-nat.c and gdbserver? Isn't it
cheaper to unify the codebase and start (transparently) using gdbserver even
for local operations?
> > * Removing local queue (waitpid_queue) would be IMHO good even for current FSF
> > GDB HEAD -
>
> It's going to happen:
http://sourceware.org/ml/gdb-patches/2009-04/msg00523.html
> pselect/ppoll would be another fancy way, but that is unuseable, as you can
> read on the BUGS section of the pselect man page.
As ppoll() is a way how to remove the local pipe entirely, what about
a workaround for non-ppoll systems by using O_ASYNC/SIGIO/sigsuspend().
Or do exist systems both without ppoll() and without O_ASYNC?
Regards,
Jan