From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1849 invoked by alias); 16 Jul 2008 17:09:35 -0000 Received: (qmail 1836 invoked by uid 22791); 16 Jul 2008 17:09:34 -0000 X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_05,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 16 Jul 2008 17:09:17 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6GH9Frq032044 for ; Wed, 16 Jul 2008 13:09:15 -0400 Received: from file.rdu.redhat.com (file.rdu.redhat.com [10.11.255.147]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6GH9E7V028674 for ; Wed, 16 Jul 2008 13:09:15 -0400 Received: from localhost.localdomain (vpn-4-106.str.redhat.com [10.32.4.106]) by file.rdu.redhat.com (8.13.1/8.13.1) with ESMTP id m6GH9Dce013021 for ; Wed, 16 Jul 2008 13:09:14 -0400 Message-ID: <487E2B39.5000503@redhat.com> Date: Wed, 16 Jul 2008 17:09:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Frysk List Subject: The Froggy project and Frysk-{Prime} and/or GDB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00058.txt.bz2 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