Re: [cdt-debug-dev] [Fwd: Re: [platform-debug-dev] Common debug services

["Alain Magloire" <alain@xxxxxxx>]

> 
> 
> 
> -------- Original Message --------
> Subject: 	Re: [platform-debug-dev] Common debug services
> Date: 	Mon, 3 Nov 2003 12:54:15 -0600
> From: 	Darin Wright <Darin_Wright@xxxxxxxxxx>
> Reply-To: 	platform-debug-dev@xxxxxxxxxxx
> To: 	platform-debug-dev@xxxxxxxxxxx
> 
> 
> 
> 
> These requests sound specific to C debugger development. The debug
> platform does not have any lauguage/architecture specific support. I
> think this request should be filed with CDT, rather than the debug
> platform.
> 
> Darin
> 
> 
> 
> 	*Haim Cohen <haim.cohen@xxxxxxxxxx>*
> Sent by: platform-debug-dev-admin@xxxxxxxxxxx
> 
> 11/03/2003 07:01 AM
> Please respond to platform-debug-dev
> 
> 	
>          To:        platform-debug-dev@xxxxxxxxxxx
>          cc:
>          Subject:        [platform-debug-dev] Common debug services
> 
> 
> 
> 
> Hi,
> 
> I am developing a DSP IDE based on Eclipse.
> I would like to suggest adding to the debug plugin few services which I
> think should be supported by the plugin.
> 
> Overview:
> Currently, in order to use the plugin to create special debugger, there
> is a need to have some command line debugger first.
> The CDT ( for example ) is using gdb as its inferior debugger.
> In the project I involve in, we use Simulator as the debug target.
> This simulator can not be integrated into gdb, since this is a system
> simulator which can simulate more than one DSP connected.
> Therefore, we used gdb only in static program context - for symbols
> locations, line<->pc, etc.
> My suggest, is to add static information support services in the debug
> plugin:
> - ELF reader (or other executables formats)
> - Dwarf2 reader (or other debug formats)
> Since the Dwarf2 is extendable, the extensions to the Dwarf2 formats can
> be in the form of ... extension points!
> I think that this kind of Dwarf reader should supply high level of debug
> information such as static scope information, types information, etc.
> 
> I will be happy to hear your comments about this.
> I also have a ready answer to the reply : "Why don't you implement it
> yourself and contribute ?" My answer : I have already implemented it
> using gdb+debug plugin, but I think that cleaner and more reusable
> implementation can be supplied by the debug-plugin developers.
> 


- CDT has an interface part of the CoreModel that describe C/C++ code.
  The information is provided by a parser working on the source files.
  In (very)brief, the Source parser creates AST then provide an adapter to create
  ICElement(s); IVariable, IMethod, ITypdef etc ...

- We also provide an interface call IBinaryParser, that will recognise symbols,
  (external, functions, globals etc ...) and provide an adapter to the ICElements.
  It is however very simple, and rely on addr2line etc .. to find more information.

Having intimate knowledge of the debug format, we could probably dissect
the binary and provide all the information to the users, for example it can be use by a
profiler or memory tracer plugin.  We've done this with STABS format.

This work was not commited in CDT, not enough bodies to push this through.