[SCM] archer-jankratochvil-stork: reverse-20080717-branchpoint-2272-g3be2de5

[SCM] archer-jankratochvil-stork: reverse-20080717-branchpoint-2272-g3be2de5

[tromey]

The branch, archer-jankratochvil-stork has been deleted
       was  3be2de5be2d72369bf6b7f26f2171653539f96cf

-----------------------------------------------------------------------
3be2de5be2d72369bf6b7f26f2171653539f96cf Proof-of-concept on fd-connected linux-nat.c server
-----------------------------------------------------------------------


hooks/post-receive
--
Repository for Project Archer.

[SCM] archer-jankratochvil-stork: reverse-20080717-branchpoint-2272-g3be2de5

[jkratoch]

The branch, archer-jankratochvil-stork has been created
        at  3be2de5be2d72369bf6b7f26f2171653539f96cf (commit)

- Log -----------------------------------------------------------------
commit 3be2de5be2d72369bf6b7f26f2171653539f96cf
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Date:   Sat May 9 17:11:47 2009 +0200

    Proof-of-concept on fd-connected linux-nat.c server
    
    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
    
    http://sourceware.org/gdb/wiki/ArcherBranchManagement
    branch archer-jankratochvil-stork
    
    Its current client is communicating over pipe with ./stork-server which is
    ptrace based.  Expecting there would be no stork-server and this pipe would be
    some socket communicating directly with kernel.
    
    Currently waitpid()+ptrace() get implemented remotely over the pipe/fd/wire as
    both need to be called from the same process to work properly with the goal to
    exercise proper remote waitpid() events handling in GDB.  Sure the abstraction
    layer should include also kill/tkill etc. but these are not interesting from
    the events processing point of view.
    
    Just while writing the code remembered Tom Tromey was discussing maybe GDB
    should always run using gdbserver and this gdbserver could be whole in the
    kernel.  While writing this code I found out I just duplicate the gdbserver
    client/protocol/server functionality. While the gdbserver protocol is
    ASCII=inefficient I do not think it is worth fixing on hardware nowadays
    - expensive is inefficient/excessive symbols reading, not the ASCII hex
    mangling/demangling.  What do you think about implementing gdbserver.ko?
    (Unfortunately I have not much knowledge on gdbserver.)
    
    It was only a proof-of-concept, the code below supports only attach
    (+cont/step/detach), spawning new inferiors (=PTRACE_TRACEME) is not supported.
    
    The change included some in fact unrelated parts:
    
    * Removing local queue (waitpid_queue) would be IMHO good even for current FSF
      GDB HEAD - replaced here by new_stork_data_event_handler, discussed there:
    +/* `new_stork_data_*' helpers are here to solve a different way the original
    +   problem described at the top-level doc by:
    +
    +   # Before we return from linux_nat_wait, we transfer all unprocessed events
    +   # from local queue back to the pipe, so that when we get back to event loop,
    +   # event loop will notice there's something more to do.
    +
    +   Stork no longer needs any local pipe for its primary functionality as it
    +   does not wait on any local SIGCHLDs.  It could use the similiar way
    +   connection to the Stork server - to send SRT_PING which would generate
    +   a response and GDB event loop would detect incoming data from the connection
    +   file descriptor.  Other way would be to create a local pipe exclusively for
    +   the notification of GDB event loop in the case all the events were processed
    +   from the file descriptor and all are stored now locally in
    +   response_waitpid_list;
    +
    +   Instead Stork uses new async_event_handler for this purpose - the original
    +   code could also use it without Stork.
    +
    +   Still push_waitpid and linux_nat_event_pipe_push originally in use had to be
    +   emulated somehow.  GDB could instead generate expected waitpid events for
    +   real by kill_lwp (plus PTRACE_CONT as the inferior is usually stopped that
    +   time which would generate no new waitpid event).  Other way would be to
    +   request returning the expected event forth and back from the Stork server.
    +   stork.c instead now generates an artificial internal-only event such as if
    +   it came from the Stork server (by a stork.c function push_waitpid).  */
    
    * Code for linux_supports_tracefork_flag and linux_supports_tracevforkdone_flag
      was removed as any utrace kernel will support it and more Stork code would be
      needed to make the tests working.
    
    Whole SIGCHLD / signals / signals masking handling is gone by this patch.
    
    Tested on Fedora 11 x86_64 today's snapshot for both sync and async mode:
    killall -9 sleep gdb stork-server;sleep 1h&pid=$!;./gdb -nx -ex "attach $pid";kill -9 $pid
    killall -9 sleep gdb stork-server;sleep 1h&pid=$!;./gdb -nx -ex "set non-stop yes" -ex "set target-async yes" -ex "attach $pid";kill -9 $pid

-----------------------------------------------------------------------


hooks/post-receive
--
Repository for Project Archer.