This is the mail archive of the
frysk@sourceware.org
mailing list for the frysk project.
Re: TaskState handleTrappedEvent
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