[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [dsdp-dd-dev] New type of launch discussion
|
You
make a good point.
So, it
is probably better to stick to what we have now, to somehow support "attaching
to a remote app",
and to
make sure the cases you mention below will work with one of the supported
launches.
Later
one, if we can come up with a clear terminology, we should clarify these
existing launches.
Marc
I think the use of "local" and "remote" have a
clear meaning in a desktop environment but not in the embedded
space.
Desktop:
local = debugging an application running
on the machine hosting the debugger
remote = debugging an
application running on a remote machine
Embedded:
- you
can debug a simulator running on the machine hosting the
debugger
- you can debug a simulator running on a remote
machine
- you can debug a device attached to the machine hosting
the debugger
- you can debug a device attached to a remote
machine (talking to the run control server over the net)
- you
can debug a device attached to the network
-
using a local run control server that drives the probe over
TCP/IP
- talking to an agent on the device
(e.g., gdb server)
I mean only to point out the challenges of picking
good terminology. Unfortunately, I don't think there's going to be a perfect set
of names for launch types that serves all these use cases, but as long as these
scenarios are kept in mind, there's a chance of coming up with something
decent.
John
At 09:03 AM 5/8/2008, Marc Khouzam wrote:
Content-class:
urn:content-classes:message
Content-Type: multipart/related;
type="multipart/alternative";
boundary="----_=_NextPart_001_01C8B114.3A28CC39"
Hello,
currently DSF-GDB supports the
following launches:
Local debugging
Attach
to local running application
Remote debugging
Besides debugging of a core file, which I will not address here,
there
is another possibility, which is to Attach to a remote running
application.
I don't believe CDI supports this. However, I would like
to add this to
DSF-GDB (as we discussed in a previous
meeting.)
Having looked at the design of such
support, I got to thinking that
the launches should be divided into two
types:
Local debugging
Remote
debugging
Each of these would support
-
start an application
- attach to running
application
I think this makes sense to a user, and allows for
the most code sharing.
It also reduces the number of launch configuration
types.
My concern is that maybe it is too late to remove the
"Attach to local running application"
launch configuration type since we
are past M7.
Any thoughts in the proposal and how to go about
it?
Thanks
<?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" />
Marc
Khouzam
Software Designer, Methods and
Tools
Ericsson Canada Inc
EMC/Q
8500
Decarie Blvd.
H4P 2N2, Mont-Royal, Qc, Canada
www.ericsson.com
Office: +514 345 7900 x42350
Fax: +514 345
6159
<?xml:namespace prefix = st1 ns =
"urn:schemas-microsoft-com:office:smarttags" />Mobile: +514 951
7191
Email:
Marc.Khouzam@xxxxxxxxxxxx
Ce courriel est confidentiel et uniquement
destiné à son ou ses destinataires. Il est défendu de le consulter, de
l'utiliser, de le dévoiler ou de le diffuser sans autorisation. Si ce message
vous est parvenu par erreur, merci d'en aviser l'expéditeur par retour de
courrier et de le détruire sans le divulguer. Un courriel et ses pièces
jointes peut être sans autorisation corrompu, interrompu, amendé, altéré et
infecté. L'entreprise ne reçoit et n'envoie de courriel qu'avec l'entente
qu'elle n'est responsable d'aucune corruption, interception, modification,
altération, infection ou conséquence possible.
This communication is
confidential and intended solely for the addressee(s). Any unauthorized
review, use, disclosure or distribution is prohibited. If you believe this
message has been sent to you in error, please notify the sender by replying to
this transmission and delete the message without disclosing it. Thank
you. E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only send
and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any consequences
thereof.
_______________________________________________
dsdp-dd-dev
mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev