[
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"
|
Roman,
See my comments inline.
----- Original Message -----
From: "Roman Levenstein" <romixlev@xxxxxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Sent: Friday, November 25, 2005 4:36 AM
Subject: Re: [cdt-dev] Startting remote program from GDB using "target
remote"
Hi Mikhail,
Thanks a lot for your advice! It was the missing piece
of the puzzle.
I played with the resumeTarget parameters and now it
seems to work more or less to my satisfaction.
But now I have some other questions:
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.
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).
We are planning to add a new extension point to simplify the usage of
extended and/or modified gdb versions and the problem you mentioned is a
part of this solution.
3) During the debugging session of the program on the
board the following situation can happen: the
developer hits a reset button on the board. In this
case, the program on the board will restart. But it
happens in the middle of debugging session from CDT's
point of view. How can I explain to CDT, that it
should just restart the debugging session or may be
just update the information with the current status of
the program on the board, e.g. again show main() as
current function, etc.
There is no solution for this problem in the current CDT frame. How your gdb
reacts when the board is reset?
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).
Thanks,
Roman
--- Mikhail Khodjaiants <mikhailk@xxxxxxx> wrote:
The "newDebugTarget" method of CDIDebugModel class
has a boolean attribute -
"resumeTarget". If you pass "false" the "run"
command will not be executed.
See "LocalRunLaunchDelegate" and
"LocalAttachLaunchDelegate" classes for
details.
----- Original Message -----
From: "Roman Levenstein" <romixlev@xxxxxxxxx>
To: <cdt-dev@xxxxxxxxxxx>
Sent: Thursday, November 24, 2005 6:27 AM
Subject: [cdt-dev] Startting remote program from GDB
using "target remote"
> Hi,
>
> We are trying to extend CDT to support our
embedded
> board.
> Our main interest is the Windows version of
> Eclispe/CDT.
>
> So far, we managed to add a support for a new
Launch
> Configuration and we are able now to automatically
> download the binaries using oor own downloader and
run
> these binaries on the board.
>
> We also have ported GDB to support our board. It
works
> from the command-line without any problems. We
use:
> target remote hotname:port and
> target remote /dev/ttyS1
>
> The problem is that we don't know how to integrate
> this GDB version into Eclispe. We managed to tell
> Eclipse that it should start our own version of
GDB
> and this works. We also tried to tell GDB that it
> should use our own .gdbinit file, but it seems
that it
> does not take it into account. And it is not clear
how
> to tell CDT that GDB should execute "target
remote"
> instead of "run" when it starts a debugging
session.
> >From the output in a console windows, I have the
> impression that CDT still tries to execute the
"run"
> command and then it tells that it cannot do it.
>
> May be I have to define my own Session class that
will
> start GDB in a custom way? But it is not clear for
me,
> how do I tell it that it should not execute "run"
on
> start, but instead "target remote". And if I
manage
> that, will CDT automatically do the rest, i.e. ask
the
> programm being debugged about its current state,
etc?
> Or should I issue a special GDB command/CDT call
after
> "target remote"???
>
> BTW, the program on the board is always in a
running
> mode, when GDB connects to it. I mean it is
already
> started and waits inside the GDB support stub for
the
> input from GDB. Should I explain this circumstance
to
> CDT somehow? May be setting the state of the
process
> to "suspended" or something else?
>
> Thanks,
> Roman
>
>
>
>
>
> __________________________________
> Yahoo! Music Unlimited
> Access over 1 million songs. Try it free.
> http://music.yahoo.com/unlimited/
> _______________________________________________
> 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
