| [dsdp-dd-dev] M6 Interface issues. |
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