* TaskState handleTrappedEvent @ 2007-10-24 15:10 Phil Muldoon 2007-10-29 10:58 ` Mark Wielaard 0 siblings, 1 reply; 4+ messages in thread From: Phil Muldoon @ 2007-10-24 15:10 UTC (permalink / raw) To: Frysk Hackers I noticed that this state is getting a little more crowded and will be even more crowded soon with watchpoints. 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. 2) I'm a little fuzzy on if there were will be an opportunity for multiple events to happen on a single sigtrap (ie breakpoint and watchpoint). I cannot think of any right now other than single step writing something to a memory address that the watchpoint is monitoring, but that should be caught on as another later sigtrap. Are there opportunities for multiple events? If so, are there any precedence issues? Regards Phil ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: TaskState handleTrappedEvent 2007-10-24 15:10 TaskState handleTrappedEvent Phil Muldoon @ 2007-10-29 10:58 ` Mark Wielaard 2007-10-30 15:48 ` Phil Muldoon 0 siblings, 1 reply; 4+ messages in thread From: Mark Wielaard @ 2007-10-29 10:58 UTC (permalink / raw) To: Phil Muldoon; +Cc: Frysk Hackers [-- Attachment #1: Type: text/plain, Size: 2844 bytes --] 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. > 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. Currently we explictly first check to see if the Task got just started, then whether we are currently on top of a breakpoint instruction, and finally whether the Isa indicates the current trapped event is a stepepd event. See Isa.isTaskStepped(Task), Task.steppingBreakpoint and Task.just_started in handleTrappedEvent. It might make sense to push these checks into LinuxWaitBuilder.stopped() where we already split out events for Stopped, Trapped and Signaled. There are also two other checks at the end to see whether or not the trapped event is an actual trap signal or something else (that we discard). See Isa.hasExecutedSpuriousTrap(Task) and task.syscall_sigret. > 2) I'm a little fuzzy on if there were will be an opportunity for > multiple events to happen on a single sigtrap (ie breakpoint and > watchpoint). I cannot think of any right now other than single step > writing something to a memory address that the watchpoint is monitoring, > but that should be caught on as another later sigtrap. Are there > opportunities for multiple events? If so, are there any precedence issues? Yes, at the moment stepping just assumes every trap event is an important event for an Instruction observer, so we just report them all (and this seems necessary since stepping onto a trapping instruction, like a breakpoint, or receiving a signal, seem to trump the actual stepping trap event). It is up to the actual Instruction observer to check whether the event was really important as a "step", we could in theory do this by checking the pc value between trap events, but that quickly becomes messy when taking instructions into account that jump to the same pc location. So in practise an TaskObserver.Instruction updateHit() means something, most likely an instruction step, happened that changed the state of the Task under observation. Cheers, Mark [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: TaskState handleTrappedEvent 2007-10-29 10:58 ` Mark Wielaard @ 2007-10-30 15:48 ` Phil Muldoon 2007-11-05 22:20 ` Mark Wielaard 0 siblings, 1 reply; 4+ messages in thread From: Phil Muldoon @ 2007-10-30 15:48 UTC (permalink / raw) To: Mark Wielaard; +Cc: Frysk Hackers 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: TaskState handleTrappedEvent 2007-10-30 15:48 ` Phil Muldoon @ 2007-11-05 22:20 ` Mark Wielaard 0 siblings, 0 replies; 4+ messages in thread From: Mark Wielaard @ 2007-11-05 22:20 UTC (permalink / raw) To: Phil Muldoon; +Cc: Frysk Hackers 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-11-05 22:20 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-10-24 15:10 TaskState handleTrappedEvent Phil Muldoon 2007-10-29 10:58 ` Mark Wielaard 2007-10-30 15:48 ` Phil Muldoon 2007-11-05 22:20 ` Mark Wielaard
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).