public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
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).