From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1711 invoked by alias); 5 Nov 2007 22:20:15 -0000 Received: (qmail 1701 invoked by uid 22791); 5 Nov 2007 22:20:15 -0000 X-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_50,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 05 Nov 2007 22:20:10 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1IpAIg-0005u0-Sm; Mon, 05 Nov 2007 23:20:07 +0100 Subject: Re: TaskState handleTrappedEvent From: Mark Wielaard To: Phil Muldoon Cc: Frysk Hackers In-Reply-To: <47275224.5090008@redhat.com> References: <471F603F.2090703@redhat.com> <1193655515.3830.72.camel@dijkstra.wildebeest.org> <47275224.5090008@redhat.com> Content-Type: text/plain Date: Mon, 05 Nov 2007 22:20:00 -0000 Message-Id: <1194301206.18745.29.camel@dijkstra.wildebeest.org> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) 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/msg00102.txt.bz2 Hi Phil, On Tue, 2007-10-30 at 15:47 +0000, Phil Muldoon wrote: > Mark Wielaard wrote: > > 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? A 'frysk core' generated event, unlike a ptrace generated event. See for example LinuxWaitBuilder.stopped() and saveFsckedOrderedKernelStoppedEvent() where we either transform the original event into a different one or reschedule the events a little before delivering to the next layer. > > 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. Yes, in handleTrappedEvent() we currently do this by checking some extra state (if isa.isTaskStepped() returns true or the pc is right at a software breakpoint instruction which we inserted ourselves and we are currently stepping that instruction, we assume it is a real step and call task.notifyInstruction(), else we assume it is a breakpoint event and call task.notifyCodeObserver() if that return -1 (no breakpoint inserted here by us) then we assume it is a trap signal event and call handleSignaledEvent(). As you said, it would be better to abstract this logic out a bit instead of having this if-then-else chain. > 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? On x86/x86_64 you should be able to detect the right variant through the debug status register, that then gives you the precedence order to check. But till now we have only dealt with one case (the step flag) and assumed it isn't set if any other reason for the trap event triggers. So you are entering new territory. If in doubt I am afraid you need to write some testcases simulating different events that all generate a trap event at the same time and look at which get through (and what debug flags are set). Cheers, Mark