[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
