Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-tcf-dev] TCF Disassembly Service

Hi Torleif,

The attached document contains the disassembly service definition we
(WR) have been discussing.  We are also think about having a command to
disassembly a buffer, but it is not in the document yet.

The idea with the "instruction field" array is that a simple disassemble
service implementation is can return the full instruction as a single
field of type "String", while a more advanced implementation can split
the instruction into typed fields to allow advanced clients to format
fields as they like, e.g. replace register names with alternatives,
replace addressed with symbolic information, etc.  A simple client who
does not want to replace any fields can simply concatenate the fields
into a string.

Any comments are welcome.

Thanks,
Felix

> -----Original Message-----
> From: dsdp-tcf-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tcf-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Sandnes, Torleif
> Sent: Thursday, March 11, 2010 4:17 AM
> To: DSDP TCF dev list
> Subject: RE: [dsdp-tcf-dev] TCF Disassembly Service
> 
> 
> Hei again Felix!
> 
> We have just started looking into how we would like the disassembly
> service to behave.
> Having visual studio shell as a frontend, we have used the Disassembly
> interface defined there as a starting point.
> (http://msdn.microsoft.com/en-us/library/bb145117%28VS.80%29.aspx)
> 
> To the Disassembly Data structure defined there we have added two
> fields that we would like to include: cycles and description. This is
> the number of cycles an instruction consumes and a description of the
> instruction respectively.
> 
> This is what we have come up with so far:
> 
> // disassemble using process context ID as handle. This enables access
> to either memory or object file.
> C * <token> * Disassembly* disassemble* <string: process context ID> *
> <string: readDataFromMemory> * <int: start address> *<int: length of
> buffer in bytes to disassemble> *
> R * <token> * <error report> * <array of  disassembly data items>*
> 
> <array of disassembly data items>
>   => null
>   => [ ]
>   => [ <disassembly data item list>]
> 
> <disassembly data item list>
>   => <object: disassembly data item>
>   => <disassembly data item list>, <object: disassembly data item>
> 
> <object: disassembly data item>
>   "activefields" : <int>
>   "address" : <string>
>   "addressOffset" : <string>
>   "codeBytes" : <string>
>   "opCode" : <string>
>   "operands" : <string>
>   "symbol" : <string>
>   "posBegin" : <object: CodeLocation>
>   "posEnd" : <object: CodeLocation>
>   "documentUrl" : <string>
>   "byteOffsetFromCodeLine" :<int>
>   "DisassemblyFlags" : <int>
>   "cycles" : <int>
>   "description" : <string>
> 
> // Disassemble a raw data buffer.
> C * <token> * Disassembly * DisassembleBuffer * <string: architecture>
> * <string: base64encoded data> *
> R * <token> * <error report> * <array of  disassembly data items> *
> architecture is either "AVR32" or_"AVR8"
> 
> I would very much like to have your comments on this and also to have
a
> look at your disassembly service.
> 
> Regards,
> Torleif Sandnes
> Atmel Norway
> 
> -----Original Message-----
> From: dsdp-tcf-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tcf-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Burton, Felix
> Sent: 8. mars 2010 21:02
> To: DSDP TCF dev list
> Subject: RE: [dsdp-tcf-dev] TCF Disassembly Service
> 
> Hej Torleif,
> 
> > Should disassemblers be implemented in the front-ends of debuggers?
> Is
> > this the case with eclipse?
> > I can see the advantages of not having to send both the object file
> and
> > source files over to TCF agents
> > but there is value in reusing a Disassembly service for different
> > front-ends.
> 
> I totally agree with you that there is value in reusing a disassembly
> service for different front-end.  We (Wind River) is currently
> discussing a disassembly service.  Once we have done some more
> prototyping we will document the service in the Eclipse TCF
repository.
> I would be happy to discuss the service definition before then if you
> like.
> 
> Thanks,
> Felix
> 
> > -----Original Message-----
> > From: dsdp-tcf-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tcf-dev-
> > bounces@xxxxxxxxxxx] On Behalf Of Sandnes, Torleif
> > Sent: Thursday, March 04, 2010 11:50 PM
> > To: DSDP TCF dev list
> > Subject: [dsdp-tcf-dev] TCF Disassembly Service
> >
> > I have looked for a TCF Disassembly service on google, in the
> archives
> > of this mailing list, in the source of the eclipse tcf plugin and in
> > the C agent implementation. The only reference I have seen to such a
> > service is on this blog
> >
> > http://nokiacarbideoneclipse.blogspot.com/2009/09/cdt-edc-
> > breakpoints.html
> >
> > Should disassemblers be implemented in the front-ends of debuggers?
> Is
> > this the case with eclipse?
> > I can see the advantages of not having to send both the object file
> and
> > source files over to TCF agents
> > but there is value in reusing a Disassembly service for different
> > front-ends.
> >
> > Has there been any thoughts on this when defining TCF?
> >
> > Thanks,
> >
> > Torleif Sandnes
> > Atmel Norway
> > _______________________________________________
> > dsdp-tcf-dev mailing list
> > dsdp-tcf-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-tcf-dev
> _______________________________________________
> dsdp-tcf-dev mailing list
> dsdp-tcf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tcf-dev
> _______________________________________________
> dsdp-tcf-dev mailing list
> dsdp-tcf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tcf-dev

Attachment: TCF Disassemble Service.doc
Description: TCF Disassemble Service.doc


Back to the top