Re: [platform-debug-dev] Extensible set of debug elements

["Darin Wright/WPG/OTI" <Darin_Wright@xxxxxxx>]

The debug core defines a basic set of "debug model" elements that model artifacts of a programming being debugged. The elements defined in core are common to most languages (i.e. applicable to Java debuggers, C++ debuggers, Cobol debuggers...). However, we want to allow a debugger to create new debug elements when neccessary - in the case that a new debugger requires a concept that the core has not allowed for. Thus, we do not want the core to statically dictate the set of all possible debug elements.

With that said, we also want the core to define elements/concepts thare are common to all debuggers.

I am interested in any feedback you can provide regarding your experience developing a debugger, and what "extensions" you might have made to core that you feel should be part of core debug.

Darin

"Alain Magloire" <alain@xxxxxxx> Sent by: platform-debug-dev-admin@xxxxxxxxxxx 11/22/2001 06:11 PM Please respond to platform-debug-dev

To:        platform-debug-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-debug-dev] Extensible set of debug elements

> 
> Currently, the debug core defines a static set of "debug elements":
> 
> * debug target
> * thread
> * stack frame
> * variable
> * value
> * register group
> * register
> * storage
> 
> We would like any "debug adapter" developers (i.e. anyone who writes an
> implementation of a debug model) to be able to define new elements if
> neccessary. To allow this, I propose that we remove (or at least deprecate)
> the method "IDebugElement.getElementType()". We will also remove (or
> deprecate) the element type constants. This way, the possible set of debug
> elements is not limited to those defined in core. Similarly, this will
> allow debug events to be fired for elements that are not defined within the
> core.

We are currently working at a debug plugin, my coworker did come up
with some set of generic Inteface that he'd liked.
Unfortunately, I did not follow this thread, could you comment more on
your ideas/project?  I do not have a full picture, except to say that
you seem to go in the right direction.


> The impact this will have is that we have some code that does "switch"
> statements based on element type - in content providers, and model
> presentations, etc. - that dispatches to different functionality based on
> element type. At worst, these can be re-coded to do "instanceof" checks.
> 
> Comments?

_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev