[dsdp-dd-dev] Is there any need for a multi-Container MI implementation?

[Frederic RISS <frederic.riss@xxxxxx>]

Hello,

As Denis presented you on the phone last week, in our team at ST we're
trying to leverage the work being done on the DSF/MI front to use with
our own debugger.

Our debugger tries to debug multiple cores at a time. This is like
having multiple debuggers which each require an MI stream, but using the
same communication pipe to Eclipse (within the same DSF session). To
handle this we simply multiplexed the MI stream in a very simple way:
 - Each MI command sent to the debugger is prefixed with the core
identifier
 - Each of the debugger MI ouputs are prefixed in the same way.

To illustrate here's the example that has already been posted by Denis
('=>' just distinguishes input from output, they're not part of the
protocol):

ARM-(ARM)
 => SAA-19-break-insert C:\soft\STM\ST_Nomadik_Toolset_1_0_0_RC2\nmf\examples\helloworld\share\host\src\example.c:176
 => SVA-20-break-insert C:\soft\STM\ST_Nomadik_Toolset_1_0_0_RC2\nmf\examples\helloworld\share\host\src\example.c:176
 => ARM-21-break-insert C:\soft\STM\ST_Nomadik_Toolset_1_0_0_RC2\nmf\examples\helloworld\share\host\src\example.c:176
ARM-21^done,bkpt={number="5",type="breakpoint",disp="keep",enabled="y",addr="0x92c",func="example",file="C:/soft/STM/ST_Nomadik_Toolset_1_0_0_RC2/nmf/examples/helloworld/share/host/src/example.c",fullname="C:/soft/STM/ST_Nomadik_Toolset_1_0_0_RC2/nmf/examples/helloworld/share/host/src/example.c",line="176",times="0"}
ARM-(ARM)
 => ARM-22-exec-continue
ARM-22^running
ARM-(ARM)
ARM-=bind-to-host,client="2",require="output"
ARM-22*stopped,reason="breakpoint-hit",bkptno="5",thread-id="0",frame={addr="0x92c",func="example",args=[{name="argc",value="Not available"},{name="argv",value="Not available"}],file="C:/soft/STM/ST_Nomadik_Toolset_1_0_0_RC2/nmf/examples/helloworld/share/host/src/example.c",fullname="C:/soft/STM/ST_Nomadik_Toolset_1_0_0_RC2/nmf/examples/helloworld/share/host/src/example.c",line="176"}
ARM-(ARM)
 => ARM-23-stack-list-frames
ARM-23^done,stack=[frame={level="0",addr="0x92c",func="example",file="C:/soft/STM/ST_Nomadik_Toolset_1_0_0_RC2/nmf/examples/helloworld/share/host/src/example.c",fullname="C:/soft/STM/ST_Nomadik_Toolset_1_0_0_RC2/nmf/examples/helloworld/share/host/src/example.c",line="176"},frame={level="1",addr="0x12a3b",func="main",file="arm_components/nmf/bare/src/main.c",fullname="",line="202"}]
ARM-(ARM)


To achieve this we obviously had to modify a bit the MI parsing and
command handling in org.eclipse.dd.mi. I don't think these modifications
make any sense to anyone else (feel free to contradict me if you think
it would be worthwhile to try to ``standardize'' this kind of thing).

What I'd like to discuss in this mail is the other part of the
modifications we did to support our usage. In a nutshell, a lot of
components assume that there's only one Container context (ie. only one
debugger), which isn't true for us. I was wondering if there might be
general interest in patches that introduces awareness of multiple
top-level contexts. 

>From what I gathered here and there, CodeSourcery develops non-stop
thread debugging for GDB. Don't know if it's directly related to the
Ericson people participating here, but if it's the case I think there're
quite some similarities with our usage. I haven't deeply investigated
this, so I could be far of. For example, wouldn't it be necessary to
make any CommandCache object methods (isTargetAvailable,
setTargetAvailable, reset) to take the target context (target thread) as
parameter?


Here's a quick summary of our modifications:
 - The aforementioned modification to CommandCache (and all services
using a CommandCache)
 - Multiple Container tracking for MIRegisters
 - Multiple Container tracking for MIStack
 - Multiple Container support for MIVariableManager

The 2 classes where we added 'tracking' of containers were modified to
hold different states depending of the requested context. 

The MIVariableManager was trivially modified to store with each
RootVariable its instantiation context and use that instead of relying
to the container stored at service initialization time.


So this was a quick overview, I won't dig any deeper in the details
before hearing back from you. We'll gladly discuss and adapt our
solutions if they can be of any use for someone else. Well, this is the
question: could you need something along these lines? 

Cheers,
Fred