frysk.rt.SteppingEngine poking at a task's blocker list?

frysk.rt.SteppingEngine poking at a task's blocker list?

[Andrew Cagney]

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.

The flexibility of this approach also lets us write custom high-level 
breakpoint observers, in the monitor say, that can be implemented using 
just the Breakpoint and its shared-library Manager, and not have to 
worry about the stepping engine at all.

Andrew

PS: And it prevents me moving this blockers stuff into frysk.proc.live 
:-( :-)

Re: frysk.rt.SteppingEngine poking at a task's blocker list?

[Tim Moore]

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

> 
> The flexibility of this approach also lets us write custom high-level
> breakpoint observers, in the monitor say, that can be implemented using
> just the Breakpoint and its shared-library Manager, and not have to
> worry about the stepping engine at all.
>

Should the stepping engine be able to step from/over any blocker, or
only breakpoints?

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGjkv6eDhWHdXrDRURAhfuAKDLORozDZHVWTXVmOvpjSYL+M+yIwCbBLmC
PsaU/RBoxyjCp2LrolM0Y2k=
=iBrX
-----END PGP SIGNATURE-----

Re: frysk.rt.SteppingEngine poking at a task's blocker list?

[Mike Cvet]

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.

Re: frysk.rt.SteppingEngine poking at a task's blocker list?

[Andrew Cagney]

Tim Moore wrote:
>> 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.
>
>   
That's the right approach; it just needs to be taken a little bit further:
-> low-level CodeObserver, implemented by frysk.proc
-> the high-level Breakpoint, as you've implemented, sub-classes 
providing ElfBreakpoints, File/Line breakpoints, DebugInfoBreakpoint and 
so on
=> the monitor can use these, as can code implementing ltrace
=> tests such as for the Display can also use those low-level 
breakpoints without getting involved with
=> in the case of the hpd and/or debug-window
>> The flexibility of this approach also lets us write custom high-level
>> breakpoint observers, in the monitor say, that can be implemented using
>> just the Breakpoint and its shared-library Manager, and not have to
>> worry about the stepping engine at all.
>>
>>     
>
> Should the stepping engine be able to step from/over any blocker, or
> only breakpoints?
>   
Only user level breakpoints; other components, such as a monitor logger 
breakpoint, are not visible.  This is all heavily reliant on the 
underlying .proc code consistently reporting breakpoints so that they 
can also be handled by the state machine; for instance:

=> step onto a breakpoint
The breakpoint fires (even though it hasn't actually executed) and 
notifies the stepper that it is blocking the thread.  The next step 
unblocks that breakpoint and re-steps

=> step-over over a function that has a breakpoint
=> step-over a line containing an embedded breakpoint
The breakpoint causes the stepping engine to stop (but an option to 
override this would be nice); the main thing is that the user breakpoint 
notifies the stepping engine so that the stepping engine can make a 
decision.

Andrew