public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Mike Cvet <mcvet@redhat.com>
To: Tim Moore <timoore@redhat.com>
Cc: Andrew Cagney <cagney@redhat.com>, frysk@sourceware.org
Subject: Re: frysk.rt.SteppingEngine poking at a task's blocker list?
Date: Fri, 06 Jul 2007 14:25:00 -0000	[thread overview]
Message-ID: <468E50B9.6050606@redhat.com> (raw)
In-Reply-To: <468E4BFB.5010604@redhat.com>

Tim Moore wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andrew Cagney wrote:
>   
>> Tim, Mike,
>>
>> I noticed this in frysk.rt.SteppingEngine:
>>
>>   /**
>>     * Unblock a task so that, from the point of view of the stepping
>>     * engine, execution can continue. For now this unblocks
>>     * instruction observers and code observers for breakpoints, but
>>     * ultimately I (timoore) think it should unblock all blockers.
>>     */
>>    public boolean continueForStepping(Task task, boolean unblockStepper) {
>>        if (unblockStepper) {
>>            task.requestUnblock(this.steppingObserver);
>>        }
>>        TaskObserver[] blockers = (TaskObserver
>> [])task.getBlockers().clone();
>>        for (int j = 0; j < blockers.length; j++) {
>>            // One of ours?
>>            if (blockers[j] instanceof Breakpoint) {
>>                task.requestUnblock(blockers[j]);
>>            } else {
>>                // Some blocker that we don't know about
>>                // System.out.println("Unknown blocker " +
>> blockers[j].toString());
>>                // return false;
>>            }
>>        }
>>        return true;
>>    }
>>
>> I'm not sure what is happening here, but the underlying code should
>> operate as:
>> -> process hits a breakpoint instruction
>> -> all low-level CodeObservers fire
>> -> all corresponding high-level Breakpoint observers fire
>> -> Breakpoint observers each notify Stepping engine to stop (accompanied
>> by corresponding low-level CodeObserver doing the block)
>> This will leave the SteppingEngine with a full list of CodeObservers to
>> unblock without needing to poke around an assumed live task's internal
>> state.
>>     
> I was going on the theory that it would be better to not have to
> interact with the stepping engine when setting breakpoints. I see below
> that you're after the same thing, which we talked about, so I'm
> surprised that you want breakpoints to depend on the stepping engine at all.
>
>   

I believe it would be best for the SteppingEngine to have some sort of 
Observer which is notified upon any breakpoint events relevent to the 
Task at hand, and deal appropriately with the situation then, instead of 
trying to run through that potential blockers list each time. So any 
time a breakpoint is set anywhere, or removed anywhere, it updates that 
Observer in the SteppingEngine.

  reply	other threads:[~2007-07-06 14:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-05 21:05 Andrew Cagney
2007-07-06 14:04 ` Tim Moore
2007-07-06 14:25   ` Mike Cvet [this message]
2007-07-06 19:38   ` Andrew Cagney

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=468E50B9.6050606@redhat.com \
    --to=mcvet@redhat.com \
    --cc=cagney@redhat.com \
    --cc=frysk@sourceware.org \
    --cc=timoore@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).