Pawel
I spent some time looking at the Wind River DFE
Interfaces, comparing them to the
current DSF set. I have some concerns that perhaps we
are missing some things. I
did not file bugs, since I could be interpreting
things incorrectly. Here are the
areas of concern.
Signals - Our TargetConnection run control area has the following
functions.
public Boolean hasSignalCapability( String context )
public void resumeWithSignal( String context, String signal
)
public void resumeWithoutSignal( String context
)
The ISignals.java DSF interface is basically empty. Seems like these
should be
captured there if/when we move to the Debug View being DSF
based.
Registers -
Out TargetConnection has register access( getRegister, setRegister
)
In
our interface these functions take the register name as a string (
assumes
register names are unique of course ). The methodology in IRegisters.java
is
of course to use variously styled DMContexts. These functions are used
for
example in SetPC Menu Actions or hover over variables in disassembly
)
E.g. setRegister( context , "pc", ... )
In order to accomplish something similar and without requiring that the
user to
data mine through all of the groups to find a particular register it
would seem
like we need some form of register creation convenience
method
public
IRegisterDMContext createRegisterDMContext( IDMContext ctx, String regName
);
Similar to how it is done in the IExpressions
interface.
Addressing
There is a helper function which returns the address size for a
debuggable context.
public void int getAddressSize( String context )
I did not see where this capability was expressed. We use this throughout
the WRS
implementation.
Randy