Does that mean that your product support
registry groups on top on CDT?
Is that going through GDB or you have your
own implementation of the generic Debug interface?
I don’t know much Eclipse and CDT
but when I started searching the code the only place I saw a CRegsiterGroup is created
is in the CRegisterManager.createMainGroup. That made me think that CDT doesn’t
support registry groups.
-----Original Message-----
From:
cdt-debug-dev-admin@xxxxxxxxxxx [mailto:cdt-debug-dev-admin@xxxxxxxxxxx] On Behalf Of Alan Boxall
Sent: Wednesday, April 28, 2004
11:52 AM
To: cdt-debug-dev@xxxxxxxxxxx
Subject: RE: [cdt-debug-dev]
Regsiter gorups in CDT
I can't take credit for the Registers View :-)
I
had implemented a Register view for my own set of debug plugins and my team
contributed the IRegisterGroup and IRegister interfaces a long time ago.
So when the core version of the Register's view appeared in R3.0 (QNX
contributed) (not sure which M level it initially appeared) I was able to
delete my own copy and move to the one supplied by the core. The
core Register's view extends the Variables view.
This
avoids the problem of multiple views that provide similar function (and in this
case even the same name) from confusing the user.
cdt-debug-dev-admin@xxxxxxxxxxx
wrote on 04/28/2004 11:31:44 AM:
> Alan, Mikhail,
> This is
the direction I was trying to go as well in my previous two e-mails.
>
>
>>> The Eclipse Debug model defines the register groups and that's
> why the GUI is based on a tree view. CDT
inserts
>
>>> only one group Main. Looks like it is a limitation of the GDB
interface.
>
>
>>> Can you guys give me some thoughts of possible enhancing the CDT
> so it can show multiple groups with the
>
>>> limitation of the current version of the MI interface. I was
> thinking in the line of coding the group name
>
>>> in the "main:pc", "group2:reg3" or something
like that.
>
>
>>> From a design point I see two options:
>
>>> 1. Ask the debugger about its register groups.
>
>>> 2. Assume the processor groups are entirely Eclipse feature and
> don’t get the debugger involved in it.
>
>>> I lean toward 1 and here is why…
>
> Can you
guys introduce yourself?
> Looks
to me that Alan owns the Register View and Mikhail the GDB integration.
> I am
currently trying to figure out how to add processor groups
> through GDB and to contribute that code to
CDT.
>
>
Mikhail,
> The
problem I have is that I don’t see a command in MI that deals
> with registry groups.
> Is it
possible for CDT to define a way so GDB implementers that feel
> that this feature is valuable will conform to
the CDT extension?
> If it
is well defined I think there will be GDB implementers in the
> embedded space that will follow and integrate
this feature.
> Or may
be we can add this feature in MI interface, it has been there
> but not implemented if I am correct.
> For
GDBs that don’t deal will groups the Main group will be added by
> default as in the current implementation.
> Or may
be another suggestion – if the registered returned by GDB
> have special symbol we can treat that as
group separator – “main::
> pc”, “group2::reg3”.
>
> Please
advise.
> Dobrin
>
>
>
-----Original Message-----
> From: cdt-debug-dev-admin@xxxxxxxxxxx
[mailto:cdt-debug-dev-
> admin@xxxxxxxxxxx] On Behalf Of Alan Boxall
> Sent: Wednesday, April 28, 2004 10:37 AM
> To: cdt-debug-dev@xxxxxxxxxxx
> Subject: [cdt-debug-dev] Regsiter gorups in
CDT
>
>
> In R3.0 there is a Register view in the core
(org.eclipse.debug.ui)
> that supports groups.
>
> I have moved from my plugin's register view
(that supported groups)
> to the core register view and it works.
>
> The IStackFrame interface will allow your
stackframe to return
> register groups (IRegisterGroup) and in turn
register groups can
> return registers (IRegister).
>
> I don't want register groups added in any way
that will make them
> persistent. My debug plugin supports
many different platforms and
> cpu architectures and must build the list of
registers and groups
> dynamically. As the user clicks
on each debug target in the debug
> view it must populate the register's view
based on the current target.
