| RE: [cdt-debug-dev] Remote debugging |
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