From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8354 invoked by alias); 9 May 2009 15:15:25 -0000 Mailing-List: contact archer-commits-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: Received: (qmail 8330 invoked by uid 9674); 9 May 2009 15:15:23 -0000 Date: Sat, 09 May 2009 15:15:00 -0000 Message-ID: <20090509151519.8299.qmail@sourceware.org> From: jkratoch@sourceware.org To: archer-commits@sourceware.org Subject: [SCM] archer-jankratochvil-stork: reverse-20080717-branchpoint-2272-g3be2de5 X-Git-Refname: refs/heads/archer-jankratochvil-stork X-Git-Reftype: branch X-Git-Oldrev: 0000000000000000000000000000000000000000 X-Git-Newrev: 3be2de5be2d72369bf6b7f26f2171653539f96cf X-SW-Source: 2009-q2/txt/msg00054.txt.bz2 List-Id: The branch, archer-jankratochvil-stork has been created at 3be2de5be2d72369bf6b7f26f2171653539f96cf (commit) - Log ----------------------------------------------------------------- commit 3be2de5be2d72369bf6b7f26f2171653539f96cf Author: Jan Kratochvil 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.