[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Startting remote program from GDB using "target remote"
|
I'm not sure that I understand the question. Why wouldn't you use the
"postCommand" method of MISession instead?
----- Original Message -----
From: "Roman Levenstein" <romixlev@xxxxxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Sent: Monday, November 28, 2005 2:37 PM
Subject: Re: [cdt-dev] Startting remote program from GDB using "target
remote"
Hi Mikhail,
Now it works. Thanks!
BTW, I'd like to submit some "free-form" commands
(i.e. not to GDB programmatically, as if they were
entered by the user or read from .gdbinit file. The
idea is to have something like .gdbinit scripts, but
to be able to execute them at any time during the
debugging. Which class/method should I look at? I
guess, I just need to get access to the input
(console) stream of GDB process and basically write
the GDB commands into it, or?
Thanks,
Roman
--- Mikhail Khodjaiants <mikhailk@xxxxxxx> wrote:
Sorry, I was mistaken. You can use the
"MITargetSelect" class to establish
remote connection. As an example, see the
implementation of
GDBServerDebugger.
----- Original Message -----
From: "Roman Levenstein" <romixlev@xxxxxxxxx>
To: "CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
Sent: Monday, November 28, 2005 9:19 AM
Subject: Re: [cdt-dev] Startting remote program from
GDB using "target
remote"
> Hi Mikhail,
>
> See my comments inline.
>
>>> 1) Now I execute "target remote" from the
.gdbinit
>>> file. This seems to work, but it is a bit
annoying
> for
>>> the customers, who have to enter the path to
this
> file
>>> for each project. Is it possible to sent this
> command
>>> directly to GDB somewhere in my launcher class
or
> in
>>> some class derived from session classes?
>>>
>>
>> You can resume your session from the launcher by
> calling the "resume" method of IDebugTarget.
>
> I don't quite understand you. How does "resume"
method
> helps me with establishing a remote connection?
What I
> need is the way to programmatically execute the
> "target remote /dev/ttyS1" command, so that the
> embedded developers do not need to enter the path
to
> the .gdbinit for each project. My guess is that it
> should be done somewhere in a
GDBCDIDebugger-derived
> class, e.g. in createLaunchSession method. But
when I
> try to do something like:
> CommandFactory factory =
> miSession.getCommandFactory();
> MIGDBSet set = factory.createMIGDBSet(new String[]
{
> "target remote myhostname:myportnumber" });
> miSession.postCommand(set);
> MIInfo info = set.getMIInfo();
>
> then it does not work as expected. What I'm doing
> wrong?
> BTW, I haven't found any Command classes for
> connections to remote targets. It is not supported
by
> CDT yet, isn't it?
>
>>> 2) Almost the same question about the path to
the
>>> custom version of GDB. Can I preset this value
>>> somewhere to point to our GDB executable and not
to
>>> the Cygwin's one by default? Should I redefine
the
> Tab
>>> class for Debugger settings for it? Or may be
>>> somewhere in the plugin.xml?
>>>
>>
>> The "official" way is to define your own debugger
by
> using the 'org.eclipse.cdt.debug.core.CDebugger"
> extension point and contribute UI for it using the
> "org.eclipse.cdt.debug.ui.CDebuggerPage" extension
> point. (see for example the implementations of
Cygwin
> debugger or gdb server).
>
> I've done as you suggested and it seems to work!
>
>>> 4) I've noticed that when GDB successfully
connects
> to
>>> the target and establishes a session, it is not
>>> possible to enter GDB commands from the console
any
>>> more. On the other hand, if it cannot establish
the
>>> connection correctly, I can enter GDB commands
from
>>> the console. What I would like to have is the
>>> possibility to enter GDB commands from console
in
> both
>>> cases. I think it cab be useful in many
situations.
>>> Any ideas how to enable it?
>>>
>>
>> I don't know why you can not enter commands to
the
> console. It should be possible if gdb is
responsive
> (the program is suspended).
>
> Sorry, it was my fault. I looked at the
application
> console, instead looking at the GDB console.
> Everything works as expected.
>
> Regards,
> Roman
>
>
>
>
>
> __________________________________
> Start your day with Yahoo! - Make it your home
page!
> http://www.yahoo.com/r/hs
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
