public inbox for archer-commits@sourceware.org help / color / mirror / Atom feed
From: jkratoch@sourceware.org To: archer-commits@sourceware.org Subject: [SCM] archer-jankratochvil-stork: reverse-20080717-branchpoint-2272-g3be2de5 Date: Sat, 09 May 2009 15:15:00 -0000 [thread overview] Message-ID: <20090509151519.8299.qmail@sourceware.org> (raw) 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.
next reply other threads:[~2009-05-09 15:15 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-05-09 15:15 jkratoch [this message] 2013-02-26 17:03 tromey
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20090509151519.8299.qmail@sourceware.org \ --to=jkratoch@sourceware.org \ --cc=archer-commits@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).