Re: Proposed frysk.rt.Display

[Andrew Cagney <cagney@redhat.com>]

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.