public inbox for
 help / color / mirror / Atom feed
From: Phil Muldoon <>
To: Mark Wielaard <>
Cc: Frysk Hackers <>
Subject: Re: TaskState handleTrappedEvent
Date: Tue, 30 Oct 2007 15:48:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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?



  reply	other threads:[~2007-10-30 15:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-24 15:10 Phil Muldoon
2007-10-29 10:58 ` Mark Wielaard
2007-10-30 15:48   ` Phil Muldoon [this message]
2007-11-05 22:20     ` Mark Wielaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).