Hi, Jan,

Thanks for the effort, but...

I talked to Eric about gdb/froggy/utrace last week and after a while it
became apparent that my impression of what I should be doing--a
wholesale replacement of ptrace/waitpid in synchronous gdb--wasn't what
he had in mind.    Apparently, what I was supposed to have been doing is
working on using froggy/utrace in asynchronous free-running threads. 
That's make vastly more sense than the wholesale replacement
thing--basically reimplementing ptrace/waitpid over a file descriptor
would add almost no functionality, would likely hurt performance at
least a little, and certainly add instability to existing function.  The
asynchronous free-running thread thing, on the other hand, takes
advantage of features of utrace/froggy not readily available with
ptrace/waitpid and is much more in keeping with what I designed froggy
for in the first place--the wholesale replacement thing would basically
have entailed throwing out more than half of froggy, and the more
interesting bits of it at that.

So, for about the third time, I'm throwing out a fair amount of work and
starting over.  This time, instead of forking froggy--which was going to
eliminate the asynchronous major bits of it that gdb wouldn't have
needed--I'm going to add direct file descriptor access to the main
branch and go with that.

Chris

Jan Kratochvil wrote:
> Hi Chris,
>
> tried to implement the file-descriptor based client for GDB as a possible
> client for the kernel module which would interface utrace.  Based on my mail:
>   http://sourceware.org/ml/archer/2009-q1/msg00257.html
>