From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29950 invoked by alias); 30 Oct 2007 15:48:03 -0000 Received: (qmail 29939 invoked by uid 22791); 30 Oct 2007 15:48:02 -0000 X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_05,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,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; Tue, 30 Oct 2007 15:47:59 +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.1) with ESMTP id l9UFltNw026254; Tue, 30 Oct 2007 11:47:55 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l9UFltr3002218; Tue, 30 Oct 2007 11:47:55 -0400 Received: from localhost.localdomain (vpn-6-10.fab.redhat.com [10.33.6.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l9UFlmJw014553; Tue, 30 Oct 2007 11:47:54 -0400 Message-ID: <47275224.5090008@redhat.com> Date: Tue, 30 Oct 2007 15:48:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Mark Wielaard CC: Frysk Hackers Subject: Re: TaskState handleTrappedEvent References: <471F603F.2090703@redhat.com> <1193655515.3830.72.camel@dijkstra.wildebeest.org> In-Reply-To: <1193655515.3830.72.camel@dijkstra.wildebeest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2007-q4/txt/msg00093.txt.bz2 Mark Wielaard wrote: > Hi Phil, > > On Wed, 2007-10-24 at 16:09 +0100, Phil Muldoon wrote: > >> I noticed that this state is getting a little more crowded and will be >> even more crowded soon with watchpoints. >> > > Yes, this comes from ptrace/wait translating all events into trap > signals. I tried to split things a little by having a separate stepping > state, but it is better to split up the trapped events into separate > (synthetic) events (see below) and then cross-checking with Chris and > Roland to make sure a future utrace layer gives us similar, but truly > separate events, with the same semantics. > What's a synthetic event? > >> Before I add my own patches >> here, some questions: >> >> 1) Is there an important order precedence here? Must it handle single >> step over breakpoints over watchpoints in any particular order? I can't >> think of why the order matters. >> > > Ideally we get an different event for different things. Since we > currently don't we have some (arbitrary) order. So to be clear several events can occur, that will only result in one sigtrap operation? So it becomes a pass-along affair; each little sub-system lints their respective status areas and if not for them, "passes" the trap along. I suppose what worries me is precedence and preservation. Say two events occurs but one sigtrap is generated. The first consumers see that it is for them, does it then continue to pass that along? Does this existing code do this now? All all sigtraps always passed along to the task at the end? Should they? Regards Phil