RE: [dsdp-dd-dev] M6 Interface issues.

["Rohrbach, Randy" <randy.rohrbach@xxxxxxxxxxxxx>]

Pawel

 

   Comments.

 

   1.)  So if we remove the signals interface we would be able to add it back in 1.1, but not before. Thats sounds reasonable.

         The interface currently has not active methods and does not seem to be referenced anywhere at this time. So it is OK

         to add a completely new Interface to a 1.1 release. That does not break the interface contract?

 

   2.) Making the createRegisterDMContext asynchronous is certainly allright. I had initially done it that way then thought we

        should model it after the IExpressions interface which is synchronous. So I guess it would look like.

 

             public void createRegisterDMContext( IDMContext ctx, String regName, DataRequestMonitor<IRegisterDMContext> rm );

 

   3.) I agree that memory is a more complicated area than our IMemory interface represents. It should be well considered since

        it can be a very complex area. So I guess we are in effect leaving this for 2.0

 

Randy

---

From: dsdp-dd-dev-bounces@xxxxxxxxxxx [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Thursday, April 03, 2008 1:26 PM
To: Device Debugging developer discussions
Subject: Re: [dsdp-dd-dev] M6 Interface issues.

Thanks Randy,

My replies below:

Rohrbach, Randy wrote:

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.

Agreed.  The DSF signals interface was never properly defined.  I filed bug 225604 to remove it for now.  We can add it back and properly define it when we have a client and a reference implementation.

       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.

I agree, this would be very convenient, and it could be readily implemented by GDB.  But I don't know if it could be as easily implemented by any other debugger.  Would an asynchronous version of this method be sufficient?  I'll file a bug for it.

      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

I suppose this should belong on the IMemory service.  Also, isLittleEndian() also belong on the IMemory service.  There's been a lot of discussion on these topics in the past though and I don't know if there ever was a clear concencus on how endianness and address size should be presented and treated in the APIs.  So I'll file a bug for it, but I'm not comfortable rushing in and adding it to the interfaces now.

-Pawel