Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dsdp-dd-dev] M6 Interfaces

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

  


Back to the top