Re: [cdt-dev] Writing a CDT debugger for a none GDB target.

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Steve Jones
> Sent: Tuesday, November 13, 2012 4:19 AM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] Writing a CDT debugger for a none GDB target.
> 
> Hi,

Hi Steve,


> I've been reading up on the Eclipse/CDT debugger interface 
> for several 
> days to try and get some insight on how I might develop code 
> to support 
> a 16-bit processor that is not supported by the GDB debugger.
> 
> I can see a CDT debugger development process that has gone 
> from CDI to DSF and finally to EDC/TCF.

That is not quite right.  It has gone from CDI to DSF with the
parallel track of EDC (which is no longer actively worked
on, see below).

> EDC got my attention as it seems to be the first attempt to move away 
> from dependency on GDB. The downside is that the reference TCF agent 
> code that the target needs to host is 54,000 lines of 'C'. Also EDC 
> seems to have been dropped from the standard CDT build which 
> seems ominous.
> 
> I can see that developing a new debugger interface is no 
> small task and 
> I'd like to get off on the right foot but I'm unsure about which 
> technology I should base my development on.

You are right that it is not a small task.  I find the fastest
solution is code re-use (see below).

> Some views and/or pointers on the following would help greatly:
> 
> 1. Has EDC died on the vine, if so why?

EDC was an effort supported by Nokia.  They have since
stopped working on it and there are no active committers focusing
in EDC.  I don't believe the effort has been picked up by others.

> 2. Is there a preferred route for CDT debugger development?

CDI or EDC are not actively being worked on.
DSF-GDB is the default debugger for CDT and is constantly being
improved (both in CDT but also in GDB itself).

> 3. Which technology base would result in the least amount of new code 
> and heartache?

What my company does is focus on DSF and GDB, and write a small
gdbstub (a la gdbserver) for our different targets.
That allows each target to re-use the existing CDT DSF-GDB
solution directly.

In your case, you says that your processor is not supported by 
the GDB debugger.  However, getting a gdbstub working for your
processor may be the simplest thing to do.  It is kind of porting
gdbserver to your processor.  gdbserver is much simpler than GDB,
and porting it seems to be something that can be relatively easy.
Then you get all of the features of GDB, and all the debug features
of CDT automatically.

> 4. Is there anything round the corner I should know about.

More features being added to GDB and DSF-GDB :)

I hope this helps.

Marc