RE: AW: [dsdp-dd-dev] RE: [cdt-debug-dev] JTAG (was: The fate of thecur

[Doug Schaefer <DSchaefer@xxxxxxx>]

I think that's where CodeSourcery's idea of target config files to house
such information makes things easier. The different launch configs can point
at the same config file. As Norbert mentioned, if you have a device such as
the Abatron BDI that is already driven by config files, you wouldn't need
much in the launch config file.

As for multi-core, the implementations I've seen have a different gdb
session for each core, which would imply different launch configurations,
which you can do already. What's missing there is an automated way to launch
multiple configurations at the same time, but that shouldn't be too hard and
should really be part of the Platform.

Anyway, this is all very good discussion. I'll continue with my prototyping
work (once CDT 3.1.1 is in the bag) and see what I can come up with.

Doug Schaefer
QNX Software Systems
Eclipse CDT Project Lead
http://cdtdoug.blogspot.com
 

-----Original Message-----
From: cdt-debug-dev-bounces@xxxxxxxxxxx
[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Friday, September 01, 2006 12:00 PM
To: CDT Debug developers list; CDT Debug developers list
Subject: RE: AW: [dsdp-dd-dev] RE: [cdt-debug-dev] JTAG (was: The fate of
thecurrent GDB suppor t in CDT)

That's the approach we're taking in our initial product, too--use the 
launch configuration to house target/connection information. However, 
it becomes limiting pretty quickly. Imagine the user having ten 
projects that he uses with a single target device. He makes a target 
related change (which is fairly common) and is now faced with 
changing ten launch configurations. You throw in multi-core, and the 
situation is even more complex and fragile. That's why RSE is 
attractive to use. In some ways, it will be overkill for even our 
intended use, but in this case we think more is better than less.

John

At 10:51 AM 9/1/2006, Doug Schaefer wrote:
>I'm just concerned that RSE would be overkill for what I'm trying to
>accomplish. From what I can see so far, a simple launch config with an
>extensiblity mechanism to configure startup commands for gdb would be
>enough. But then I'm a keep it simple kind of guy :).
>
>Doug Schaefer
>QNX Software Systems
>Eclipse CDT Project Lead
>http://cdtdoug.blogspot.com
>
>
>-----Original Message-----
>From: cdt-debug-dev-bounces@xxxxxxxxxxx
>[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
>Sent: Friday, September 01, 2006 11:16 AM
>To: CDT Debug developers list; CDT Debug developers list
>Subject: Re: AW: [dsdp-dd-dev] RE: [cdt-debug-dev] JTAG (was: The fate of
>thecurrent GDB suppor t in CDT)
>
>We hope that RSE (Remote System Explorer) will eventually fill that
>role, and have already started some prototyping towards that end. We
>hope to be active participants in its development starting in a month
>or two. I believe others in the dsdp group are looking at RSE in the same
>way.
>
>John
>
>At 10:11 AM 9/1/2006, Ploett, Norbert wrote:
> >Daniel / Doug,
> >
> > > Just like in CDT, or in Eclipse as a whole, it's important to think
> > > about the correct abstraction layer for any task.  We ship a set of
> >
> >this reminds me of the discussions I read on the DSDP TM list about
> >board description standards and such stuff. I have not followed this
> >very closely, but isn't this the mission of DSDP TM, to provide
> >abstractions for all sorts of target systems, including JTAG probe
> >controlled boards?
> >
> >Just another thought
> >
> >
> >Norbert
> >_______________________________________________
> >cdt-debug-dev mailing list
> >cdt-debug-dev@xxxxxxxxxxx
> >https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
>_______________________________________________
>cdt-debug-dev mailing list
>cdt-debug-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>_______________________________________________
>cdt-debug-dev mailing list
>cdt-debug-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev