public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Phil Muldoon <pmuldoon@redhat.com>
Cc: Frysk Hackers <frysk@sourceware.org>
Subject: Re: TaskState handleTrappedEvent
Date: Mon, 29 Oct 2007 10:58:00 -0000	[thread overview]
Message-ID: <1193655515.3830.72.camel@dijkstra.wildebeest.org> (raw)
In-Reply-To: <471F603F.2090703@redhat.com>

[-- 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 --]

  reply	other threads:[~2007-10-29 10:58 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 [this message]
2007-10-30 15:48   ` Phil Muldoon
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=1193655515.3830.72.camel@dijkstra.wildebeest.org \
    --to=mark@klomp.org \
    --cc=frysk@sourceware.org \
    --cc=pmuldoon@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).