From: Phil Muldoon <pmuldoon@redhat.com>
To: Frysk List <frysk@sourceware.org>
Subject: The Froggy project and Frysk-{Prime} and/or GDB
Date: Wed, 16 Jul 2008 17:09:00 -0000 [thread overview]
Message-ID: <487E2B39.5000503@redhat.com> (raw)
Over on the utrace-devel list there is a thread about ntrace, and ideas
about how the user-land interface to utrace should look. Thread is here:
https://www.redhat.com/archives/utrace-devel/2008-July/msg00007.html
Chris Moller has started a project called Froggy which realizes these
user-land requirements. The code base and announcements are here:
https://www.redhat.com/archives/utrace-devel/2008-July/msg00039.html
One of this issues we have been looking at as we examine Frysk and its
replacement are the farther reaching aspects of debuggers/tools in the
future. The utrace project forms a part of this, as does Froggy. It is
important at least from our perspective to get our requirements in early.
Anyone who has worked with ptrace for any amount of time normally has
some pet-peeve, or worse, some horror story. Ptrace does some things
right, and some things wrong. I'm not going down the road of why, but I
believe there is a golden opportunity here to present Froggy and utrace
with a listing of living requirements from the debugger community. I'll
volunteer to organize the requirements document if you volunteer your
opinions in the spirit of open discourse. I'm especially interested in
current ptrace use-case limitations, something like:
"Reading large amounts of memory from an inferior via ptrace is slow.
Peeking word after word, especially when dumping corefiles is plain
painful. Lots of people get around this by accessing the inferior's
/proc/self/mem. But this requires the inferior to be ptrace_attach'ed;
so it can be granted access to /proc/self/mem and direct reads. This is
a problem as is if a ptrace'd child gets a signal, it is stopped. In the
real-time world this is a problem, and is undesirable; we simply want
high-bandwidth access to the inferior's memory."
If we can coalesce these use-cases into requirements, it can form high
bandwidth communications with Froggy and utrace.
Comments?
Regards
Phil
reply other threads:[~2008-07-16 17:09 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=487E2B39.5000503@redhat.com \
--to=pmuldoon@redhat.com \
--cc=frysk@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: link
Be 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).