[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-debug-dev] Remote debugging
|
Just to give some perspective on this (since QNX is developing an IDE
which is based on these concepts) this is some of the detail of the
QNX approach which is based off of the CDT.
QNX provides our own extension of the generic C/C++ Nature and it enhances
the project information with target details (in our case we can build
for multiple targets concurrently so we have to handle that case). Initially
the build may not know about the _real_ target but only know about the
target tools (ie which cross-compilers to use). For this you might need
to add logic to the builder extension (potentially creating your own). The
CDT build model is currently very (very) simple, but as people get involved
hopefully this will change (hint, hint for the lurkers =;-). The simple
builder allows us to put the smarts into the make (which has lots of cons,
but is simple).
When the project is then "launched" (be it run or debug) the launch
configuration which is used can be a QNX target configuration, which
again is derived from the standard CDT launch configuration. We have
extended it to require the selection of a QNX target machine (which are
set-up/configured using some other target agent which may or may not
be GDB). This is decoupled because launching != debugging (think about
"run" in the local case ... no debugging there). This means that when
we are self-hosted you have the choice of running your applications
locally (default CDT launcher) _or_ using some target agent (QNX launcher).
Now this is how we have done it. It gives us flexibility of controlling
pieces (like remote targets) when we need to and using the default CDT
behviour as well. Thoughts and comments welcome.
Hope this helps,
Thomas
On Wed, 16 Oct 2002, Lescuyer, Martin wrote:
> Right, but expanding this to the build information (which make sense as far
> as the choice of a build toolchain, or even a compilation flag could have an
> impact on the target configuration/definition), implies that Launch
> Configuration is not the right location to interact with the user, but an
> eventual Build Configuration would not be a good candidate neither.
> This may require another concept.
>
> Martin
>
> -----Message d'origine-----
> De : Brian Moyle [mailto:bmoyle@xxxxxxxxxx]
> Envoye : mardi 15 octobre 2002 03:16
> A : cdt-debug-dev@xxxxxxxxxxx
> Objet : Re: [cdt-debug-dev] Remote debugging
>
>
> One common reason for using gdbserver on a remote target is to help debug
> cross-compiled applications. I would like to see a way to select from a
> list of
> available targets, and allow a new builder and new debug (features<?>) to
> modify
> the environment appropriate to that target. For example, I might want to
> create
> and name a ppc target, entering in the appropriate network, cross-compile,
> cross-debug, and deployment information (e.g., how to get the application to
> the
> target). Once it had been configured, the build and debug would "just
> work."
> The user could then select from, say, a pre-configured mips target, rebuild,
> and
> debug against that target, as well. Unfortunately, I honestly don't know
> how to
> best fit that concept into the Eclipse framework, an still manage to keep it
>
> tightly integrated and consistent.
>
> Is there a way to take your suggestions and expand it to include builder
> information as well? If so, "Launch Configuration" may not be the right
> place
> to make the "Remote <vendor> target" associations, but the concept is still
> there.
>
> Brian
>
>
> Lescuyer, Martin wrote:
> > All,
> >
> > >> Right now, I'm passing remote connection parameters as a String[].
> > That =
> > >> works
> > >> for me, but I'm open to other suggestions (an interface to describe =
> > >> target
> > >> connection interface, for example.)
> > >>
> > >
> > >An interresting question, What is a "Target/Hostname" in eclipse and
> > how to represent it.
> > >To make things easier I would prefer the user be presented with a
> > view, a tree containning
> > >a list of the potential "targets" on the network. You would also want
> > to query the targets
> > >to get the architecture, obviously you do not want to debug an x86
> > program on Mips board etc ..
> > >All sort of nice possibilities if we have an interface defining what
> > is a "target".
> >
> > Obviously predetermining the list of data required to define what is a
> > target may not be reasonable because each target has its own properties.
> > This property list must be extensible so that any target could be
> > described (even exotic ones requiring memory mapping definition and/or
> > port definitions... (target configuration)). Such data are defined by
> > the software vendor, and filled by the user. From the CDT-perspective,
> > only the user can fill such data, the CDT just has to give access to
> > them, on a RW-basis.
> >
> > In this context, the list of "potential targets on the network" would be
> > like the list of "installed PlugIns" (do not know if this would be some
> > eclipse plugins or not) allowing to execute/debug an application.
> >
> > Creating a new Launch Configuration seems to be a good candidate for the
> > moment when the user associates an executable program with a target
> > (selected from a list of installed vendor-"plugIns" ). The CDT then
> > gives access to the list of data describing the selected target. The CDT
> > gives a RW-access though MI to these data (a kind of Manifest Editor),
> > based on an extensible XML file. The DTD has to exhibit a set of
> > XML-elements, each one associated with a CDT-known kind of graphic
> > widgets (text field, property list, radio-button) so that all the data
> > we can imagine could be described and accessed through the CDT UI.
> >
> > In this context, going back to the initial "remote debugging" use case,
> > it would be when creating the Launch Configuration that the user would
> > select "Remote <Vendor> target" where <Vendor> would stand for RedHat,
> > QNX..., and that the remote parameters required by the vendor would then
> > be filled by the user. Controlling that the executable application and
> > the selected target are compatible would be made later, when trying to
> > execute or debug.
> >
> > Does this make sense ?
> >
> > I started to dig in the code of the PDEMultiPageXMLEditor to see how
> > "easy" it was to re-use. If anyone has (good or bad) experience in
> > reusing this class, I'd appreciate very much the feedback, because easy
> > may not be appropriate...
> >
> > Martin
>
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
-------------------------------------------------------------
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@xxxxxxx OS Technology Developer
(613)-591-0931 http://www.qnx.com/
