Proposed frysk.rt.Display

Proposed frysk.rt.Display

[Adam Jocksch]

 From a discussion with Andrew:
 > What is needed here is a higher level abstraction, a frysk.rt.Display 
(I'm not using Watch as that implies hardware
 > WatchPoint) object, say, that worries about scope rules, and changing 
location, and being able to save/restore
 > itself.  The display object, when the program stops, would know to 
re-instantiate the underlying Variable (if still in
 > scope) when the process stops.

So, mulling it over it sounds like frysk.rt.Display needs to have the 
following
    - an isInScope() method or something akin to it in functionality
    - some reference to the Variable itself. I'm guess that something 
like private Variable myVar is probably not what's
      needed here; so should we be storing the variable's Location? or 
the higher level source#line#col?
    - all of the value-access functionality already implemented in 
Variable (or a way to get a Variable from a Display,
      then call get Int or whatever on it)

The second point is probably the trickiest one, and the point where I 
have the least idea of what would be sufficient/best.

Adam

Re: Proposed frysk.rt.Display

[Sami Wagiaalla]

Can you provide more context here please.
What is the problem the proposed Display object is solving ?

Adam Jocksch wrote:
> From a discussion with Andrew:
> > What is needed here is a higher level abstraction, a 
> frysk.rt.Display (I'm not using Watch as that implies hardware
> > WatchPoint) object, say, that worries about scope rules, and 
> changing location, and being able to save/restore
> > itself.  The display object, when the program stops, would know to 
> re-instantiate the underlying Variable (if still in
> > scope) when the process stops.
>
> So, mulling it over it sounds like frysk.rt.Display needs to have the 
> following
>    - an isInScope() method or something akin to it in functionality
>    - some reference to the Variable itself. I'm guess that something 
> like private Variable myVar is probably not what's
>      needed here; so should we be storing the variable's Location? or 
> the higher level source#line#col?
>    - all of the value-access functionality already implemented in 
> Variable (or a way to get a Variable from a Display,
>      then call get Int or whatever on it)
>
> The second point is probably the trickiest one, and the point where I 
> have the least idea of what would be sufficient/best.
>
> Adam

Re: Proposed frysk.rt.Display

[Adam Jocksch]

Sami Wagiaalla wrote:
> Can you provide more context here please.
> What is the problem the proposed Display object is solving ?
>
The problem is that a Variable object has no concept of when it is in or 
out of scope, as well as when it changes from being in memory to being 
in a register. The Display class will act as a sort of intermediary 
between Variable and classes that wish to access Variables (such as 
variable watches in the source window), such that they will not need to 
worry about checking whether the variable is still in scope, in memory 
or in a register, etc.

Re: Proposed frysk.rt.Display

[Sami Wagiaalla]

> The problem is that a Variable object has no concept of when it is in 
> or out of scope, as well as when it changes from being in memory to 
> being in a register. The Display class will act as a sort of 
> intermediary between Variable and classes that wish to access 
> Variables (such as variable watches in the source window), such that 
> they will not need to worry about checking whether the variable is 
> still in scope, in memory or in a register, etc.

Ah cool... thanx :)

Re: Proposed frysk.rt.Display

[Andrew Cagney]

Adam,

This is a good summary, even the text to put at the top of the task as 
the description :-)

First thing I think we've identified is that frysk.value.Variable is 
misleading, should be renamed to .Value -- compiler people are familar 
with lval and rval as extensions of that :-)  It also leads to things 
like getRegisterVariable -> getRegisterValue - more sane :-)

That leaves Variable for you and sami to fight over.  I wonder though if 
for this object, something like VariableMonitor, or VariableTracker will 
be more meaningful.

Anyway, the technical challenge here, I think, is defining the  
test-cases that are needed to push this object through each of its 
possible state transitions.  I put it that way as, that way the 
test-cases define the objects requirements through hard evidence - and 
we don't end up with code that probably isn't needed.

So, assuming for now that there's .getValue(), and a constructor, the 
most basic of tests would be, given:

    int x = 0;
    x = 1;         // breakpoint #1
    x = 2;         // breakpoint #2

run to breakpoint 1, create the object, continue to breakpoint #2, check 
the object changed.  With this unit test running we can then start to 
expand the cases this code needs to cover.

--

A side line here, the obvious way to implement this is by creating 
high-level FileLineBreakpoint()s using hard-wired addresses.  Lets be a 
little inovative though :-)  Instead why not add to frysk.testbed code 
to find a pattern given a file (perhaps there's a library method 
available), and then create a FilePatternBreakpoint instead for 
instance, something like:

    new FilePatternBreakpoint(new File(getSrcDir(), "path-to.c"), "x = 1;")

going forward I think this will greatly simplify the authoring and 
clarity of these tests.

Andrew




Adam Jocksch wrote:
> Sami Wagiaalla wrote:
>> Can you provide more context here please.
>> What is the problem the proposed Display object is solving ?
>>
> The problem is that a Variable object has no concept of when it is in 
> or out of scope, as well as when it changes from being in memory to 
> being in a register. The Display class will act as a sort of 
> intermediary between Variable and classes that wish to access 
> Variables (such as variable watches in the source window), such that 
> they will not need to worry about checking whether the variable is 
> still in scope, in memory or in a register, etc.

Re: Proposed frysk.rt.Display

[Stan Cox]

On Thu, 2007-05-10 at 07:05 -0700, Andrew Cagney wrote:
> should be renamed to .Value

Done.
http://sources.redhat.com/ml/frysk-cvs/2007-q2/msg00344.html