What the CDT Debugger is meant to be (was RE: [cdt-debug-dev] Re: cdt-d

[Thomas Fletcher <ThomasF@xxxxxxx>]

>-----Original Message-----
>From: Øyvind Harboe [mailto:oyvind.harboe@xxxxxxxxx]
>Sent: May 21, 2004 12:52 PM
>To: cdt-debug-dev@xxxxxxxxxxx; bjoern.m.haase@xxxxxx
>Subject: [cdt-debug-dev] Re: cdt-debug-dev digest, Vol 1 #223 - 9 msgs
>

[Thankfull comments snipped]

>My plan is to build, and make available for download, a hacked up CDT
>plugin from CVS HEAD with the changes I outlined. That plan has so far
>been foiled by various hickups in the build process, that most likely
>are resolved early next week. 

[Plans for patch snipped]

I thought that with all of the discussion about how the debugger should
and shouldn't work, that I would provide some "guidance" on how the CDT
debugger was designed to be adapted, and consequently hopefully give you
the right foundation for developing your patch.  I do this since I hate
to see wasted effort; if your patch is only making the world better for
GDB users at the expense of other CDI users, then it is likely going to
be rejected, and that would be a shame.

So starting from the top (Alain and Mikhail will correct me where I'm
wrong):

1) The CDI interface is a C/C++ specific extension to the eclipse
generalized
debugger interface.  The goal of the CDI is to provide a debugger
independant,
_generalized_ interface by which higher level components (ie a UML debugger)

would be able to interact with a debug session.

So at this point we have:
[ Eclipse Core   ]
[ Eclipse Debug  ]
[ CDT CDI        ]
[ Your Debugger Implementation ]

2) Since it is generally useless to have a C/C++ development without some
sort
of debugger, a default/sample implementation was provided using 'gdb'. In
order
to make the sample meaningfull, a sample for a launch configuration was also
provided which (initially) only supported local hosted debugging.  

So at this point we have:
[ Eclipse Core   ]
[ Eclipse Debug  ]
[ CDT CDI        ]
[ GDB debugger via MI* ] [ Your Launch Implementation ]

*= Extension point

Of course this isn't very usefull without a way to launch gdb, so a _simple_
and
_generic_ launch configuration which integrated into Eclipse's launch model
was
created. It was designed so that other OEM/VARs which which wanted to use
gdb as 
a debugger, but in a specialized manner (or a specialized version) could
extend 
it.

So at this point we have:
[ Eclipse Core   ]
[ Eclipse Debug  ]
[ CDT CDI        ]
[ GDB debugger via MI* ]         [ Simple GDB Launch* ]
[ Your OEM/VAR custom GDB here ] [ Your OEM/VAR custom launch here ]

*= Extension point

This allows people shipping product with CDT to fill in the custom extension

points as they see fit.  The kinds of customizations which you are
interested
in doing are really a new launch configuration.  This launch configuration 
is specific to gdb (though not a particular type of gdb) and is more
flexible
than the current implementation, but less friendly for OEM/ISV folks who
generally want more complete control to drive the environment.  

So at this point you would create a _NEW_ launch :
[ Eclipse Core   ]
[ Eclipse Debug  ]
[ CDT CDI        ]
[ GDB debugger via MI* ]   [Super Flexible User launch configuration ]
[ Your specified GDB here] 

*= Extension point

Note that your launch configuration (and potentially debugger extensions)
can 
co-exist with the Simple GDB Launch and/or any OEM/VAR launch.  You can 
put all of the flexibility into the launcher to make it just like DDD if
you so desire.  Think of it as just another OEM launch capability where
you are providing a full flexibility to the user.

Hope this helps,
 Thomas