Re: Proof-of-concept on fd-connected linux-nat.c server

[Pedro Alves <pedro@codesourcery.com>]

On Sunday 10 May 2009 15:55:49, Jan Kratochvil wrote:

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

I don't disagree with ptrace's use of signals assessment, but,
moving *gdb specific* interfaces to kernel space, and having to rely
on a kernel module seems like the wrong direction to me.  I consider
having the bulk of the work done on userspace a feature (as long as it
doesn't get in the way).

> (As i do not work on this project I may not know it all.)

Neither do I.  :-)

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

Okay, we're talking about slightly different things.  I was talking
about the remote debugging part.  Putting too low level
actions through a remote interface is a mistake, IMO.

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

Probably, I think we're slowly going in that direction.  Making the
debug interface control parts of gdbserver into a library and reuse
it from gdb for native debugging (code sharing, that is) as been
suggested many times.

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

If we have to support older systems (not so old actually), and
other unixes, maintaining yet another way of waking up the
event-loop, and managing event sources, doesn't sound like it has
any benefit.  If you go the sigsuspend path, you have to
rely on signals for all kinds of wake ups and event sources;
SIGIO isn't a panacea either ---  SIGIO notifications on a pipe
doesn't work on all systems; if python or something else wants to
use it, you're in trouble too.  The self-pipe trick
works everywhere select on file descriptor works, so it
seems best to just stick to it.

-- 
Pedro Alves