This is the mail archive of the mailing list for the Archer 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: 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:
> 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?


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