* RE: remote debugging
@ 2003-06-13 14:24 nak26
0 siblings, 0 replies; 27+ messages in thread
From: nak26 @ 2003-06-13 14:24 UTC (permalink / raw)
To: Brijesh Shukla, Quality Quorum; +Cc: gdb
>> gdb> load
>
>You should not do that, gdbserver already loaded the program.
>The rest of your problems may be related to this step.
>
What works for me is
1.) gdb> file executable_name
--That, of course, works if you built the executable locally, and also have
access --to the code
2.) gdb> break break_point_somewhere
3.) gdb> continue
--Don't do run, since gdbserver has already fired the process (on the remote
--machine).
--Nik
^ permalink raw reply [flat|nested] 27+ messages in thread
* Remote debugging
@ 2015-03-07 13:52 Russell Shaw
2015-03-07 14:09 ` Ofir Cohen
0 siblings, 1 reply; 27+ messages in thread
From: Russell Shaw @ 2015-03-07 13:52 UTC (permalink / raw)
To: gdb
Hi,
I'm trying to set up running gdbserver on a laptop and ddd/gdb on a desktop pc.
Apart from exporting an NFS directory from the laptop, what other easy way is
there to get the compiled binary debugee automatically transferred from the
desktop to the laptop?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Remote debugging
2015-03-07 13:52 Remote debugging Russell Shaw
@ 2015-03-07 14:09 ` Ofir Cohen
2015-03-08 7:48 ` Russell Shaw
0 siblings, 1 reply; 27+ messages in thread
From: Ofir Cohen @ 2015-03-07 14:09 UTC (permalink / raw)
To: Russell Shaw; +Cc: gdb
Hi Russel,
I hope this is what you're looking for.
I see two approaches:
1) File system sharing/copying utility
Similar to what you suggested, NFS, scp, etc.
I do remote debugging all the time with gdb and gdbserver, and I have this
batch file (both my host and target are Windows OSes) that copies
my binaries
over SMB share.
If you build your sources frequently, and you're paranoid about
typing the same commands
over and over again, how about adding a post-build command to call
this script to deploy the files?
2) Transferring files via remote protocol
Once you're connected from gdb to gdbserver, you can use the
following command [1]:
remote put <host file> <target file>
However, this might be an overkill as it will require gdbserver
[2] to be attached to
some dummy process, and will most likely require you to start new
gdb and gdbserver
processes in order to debug the new binary.
I personally consider option #1 as a valid and normal way of
host2target remote debugging workflow.
- Ofir
[1] https://sourceware.org/gdb/onlinedocs/gdb/File-Transfer.html
[2] https://ftp.gnu.org/old-gnu/Manuals/gdb-5.1.1/html_node/gdb_130.html
On 7 March 2015 at 15:52, Russell Shaw <rjshaw@netspace.net.au> wrote:
> Hi,
> I'm trying to set up running gdbserver on a laptop and ddd/gdb on a desktop
> pc.
>
> Apart from exporting an NFS directory from the laptop, what other easy way
> is there to get the compiled binary debugee automatically transferred from
> the desktop to the laptop?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Remote debugging
2015-03-07 14:09 ` Ofir Cohen
@ 2015-03-08 7:48 ` Russell Shaw
0 siblings, 0 replies; 27+ messages in thread
From: Russell Shaw @ 2015-03-08 7:48 UTC (permalink / raw)
Cc: gdb
On 08/03/15 01:09, Ofir Cohen wrote:
> Hi Russel,
> I hope this is what you're looking for.
>
> I see two approaches:
> 1) File system sharing/copying utility
> Similar to what you suggested, NFS, scp, etc.
>
> I do remote debugging all the time with gdb and gdbserver, and I have this
> batch file (both my host and target are Windows OSes) that copies
> my binaries
> over SMB share.
>
> If you build your sources frequently, and you're paranoid about
> typing the same commands
> over and over again, how about adding a post-build command to call
> this script to deploy the files?
>
>
> 2) Transferring files via remote protocol
> Once you're connected from gdb to gdbserver, you can use the
> following command [1]:
> remote put <host file> <target file>
>
> However, this might be an overkill as it will require gdbserver
> [2] to be attached to
> some dummy process, and will most likely require you to start new
> gdb and gdbserver
> processes in order to debug the new binary.
>
> I personally consider option #1 as a valid and normal way of
> host2target remote debugging workflow.
Hi,
I put in /home/russell/myprogdir/.gdbinit:
target extended-remote main:1234
cd /home/russell/myprogdir
file myprog
remote put myprog myprog2
break main
run
define hook-run
kill
file myprog
remote put myprog myprog2
end
I was going to do on the laptop (the above test is all in the same directory on
the same pc):
gdbserver main:1234 myprog2
When testing with gdbserver invoked on the same pc (main) in the same directory
(/home/russell/myprogdir), "myprog" is truncated to 0 bytes by "remote put
myprog myprog", so i had to use myprog2 for the copy. I filed a bug for that.
"remote put" should first copy myprog to /tmp/, open the remote myprog for
writing (which truncates it), then copy from /tmp/. Another way is to note the
source and dest are the same, and skip the copying.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Remote debugging
@ 2004-03-22 14:23 luca risso
0 siblings, 0 replies; 27+ messages in thread
From: luca risso @ 2004-03-22 14:23 UTC (permalink / raw)
To: drow; +Cc: gdb
>On Fri, Mar 19, 2004 at 10:13:40AM +0000, luca risso wrote:
> > Hi,
> >
> > I'm trying to debug an application running on a PPC board with Linux
>2.4.25.
> >
> > I'm new about this kind of environment so please don't be surprised if
>my
> > question seems too silly.
> > Using GDBServer I can run the program on the target and set breakpoints
>to
> > stop a thread.
> > I seems to me that should be possible (I've still not experinced that)
>also
> > to stop all threads of a process on the same breakpoint.
> >
> > Now, is it possible someway to stop all processes running on the board?
> > It would be useful when debugging processes sending messages to each
>other.
> > Something similar is available using psos and VxWorks environments where
> > all processes seems to be "freezed" at a time.
>
>No, it's not possible. GDB can only manage one process at a time.
>
>By the way, every time you stop a thread, GDB arranges for all threads
>in that process to stop. GDB doesn't currently support any other mode.
>
In this case, for such an embedded appilcation, do you think it could be
reasonable to compile all the application stuff along with the Linux kernel?
Then probably my program would appear as a kernel thread (??) so that it can
be debugged using gdb stubs for kernel debugging.
Do you see any drawback in this approach?
Is there a "standard" or "common" approach for this kind of application?
Thanks a lot. Regards.
Luca
_________________________________________________________________
Filtri antispamming e antivirus per la tua casella di posta
http://www.msn.it/msn/hotmail
^ permalink raw reply [flat|nested] 27+ messages in thread
* Remote debugging
@ 2004-03-19 17:59 luca risso
2004-03-19 18:43 ` Daniel Jacobowitz
0 siblings, 1 reply; 27+ messages in thread
From: luca risso @ 2004-03-19 17:59 UTC (permalink / raw)
To: gdb
Hi,
I'm trying to debug an application running on a PPC board with Linux 2.4.25.
I'm new about this kind of environment so please don't be surprised if my
question seems too silly.
Using GDBServer I can run the program on the target and set breakpoints to
stop a thread.
I seems to me that should be possible (I've still not experinced that) also
to stop all threads of a process on the same breakpoint.
Now, is it possible someway to stop all processes running on the board?
It would be useful when debugging processes sending messages to each other.
Something similar is available using psos and VxWorks environments where all
processes seems to be "freezed" at a time.
May it be useful to compile all my stuff along with Linux and then use gdb
stubs normaly adopted for kernel debugging?
Thanks for your help
Luca
_________________________________________________________________
Get reliable access on MSN 9 Dial-up. 3 months for the price of 1!
(Limited-time offer) http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Remote debugging
2004-03-19 17:59 luca risso
@ 2004-03-19 18:43 ` Daniel Jacobowitz
0 siblings, 0 replies; 27+ messages in thread
From: Daniel Jacobowitz @ 2004-03-19 18:43 UTC (permalink / raw)
To: luca risso; +Cc: gdb
On Fri, Mar 19, 2004 at 10:13:40AM +0000, luca risso wrote:
> Hi,
>
> I'm trying to debug an application running on a PPC board with Linux 2.4.25.
>
> I'm new about this kind of environment so please don't be surprised if my
> question seems too silly.
> Using GDBServer I can run the program on the target and set breakpoints to
> stop a thread.
> I seems to me that should be possible (I've still not experinced that) also
> to stop all threads of a process on the same breakpoint.
>
> Now, is it possible someway to stop all processes running on the board?
> It would be useful when debugging processes sending messages to each other.
> Something similar is available using psos and VxWorks environments where
> all processes seems to be "freezed" at a time.
No, it's not possible. GDB can only manage one process at a time.
By the way, every time you stop a thread, GDB arranges for all threads
in that process to stop. GDB doesn't currently support any other mode.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 27+ messages in thread
* remote debugging
@ 2003-06-13 7:50 Brijesh Shukla
2003-06-13 13:28 ` Quality Quorum
0 siblings, 1 reply; 27+ messages in thread
From: Brijesh Shukla @ 2003-06-13 7:50 UTC (permalink / raw)
To: gdb
Hello,
Can any body explain the remote debugging application in Linux.
currently for testing purpose as simple case, I have chosen two i686
Pentium machines with Linux
installed on two systems. on system I am running gdb and in another
system I am running gdb server. I did the following steps.
Target:
gdbserver host:port program
//Now gdbserver has been started
Host:
// I compiled the simple hello word program as gcc -g program.c -o
program
// copied the program into target system
gdb program
gdb> target remote host:port
gdb>
// connection established
gdb> load
// it is showing loading the sections, I m not sure the addresses from
local machine or from target machine ( how can I verify ? in our
case,sicne both machine
are same architecture and same OS)
I can set break point to main.
if I do step or next, I am getting the error message "cannot find
bounds of current function"
if I do continue, I am getting the error message " program received
SIGSEGV, segmentation fault"
can anybody tell me where is the wrong ?
Is there anything's need to be take care while building the gdb in one
machine. ? currently I am using the default gdb installed in machine
due to both machine are same architecture.
Regards
Brijesh Shukla
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: remote debugging
2003-06-13 7:50 remote debugging Brijesh Shukla
@ 2003-06-13 13:28 ` Quality Quorum
0 siblings, 0 replies; 27+ messages in thread
From: Quality Quorum @ 2003-06-13 13:28 UTC (permalink / raw)
To: Brijesh Shukla; +Cc: gdb
On Fri, 13 Jun 2003, Brijesh Shukla wrote:
> Hello,
>
> Can any body explain the remote debugging application in Linux.
> currently for testing purpose as simple case, I have chosen two i686
> Pentium machines with Linux
> installed on two systems. on system I am running gdb and in another
> system I am running gdb server. I did the following steps.
>
> Target:
> gdbserver host:port program
>
> //Now gdbserver has been started
>
> Host:
>
> // I compiled the simple hello word program as gcc -g program.c -o
> program
> // copied the program into target system
>
> gdb program
> gdb> target remote host:port
> gdb>
>
> // connection established
> gdb> load
You should not do that, gdbserver already loaded the program.
The rest of your problems may be related to this step.
>
> // it is showing loading the sections, I m not sure the addresses from
> local machine or from target machine ( how can I verify ? in our
> case,sicne both machine
> are same architecture and same OS)
>
> I can set break point to main.
>
> if I do step or next, I am getting the error message "cannot find
> bounds of current function"
>
> if I do continue, I am getting the error message " program received
> SIGSEGV, segmentation fault"
>
> can anybody tell me where is the wrong ?
>
> Is there anything's need to be take care while building the gdb in one
> machine. ? currently I am using the default gdb installed in machine
> due to both machine are same architecture.
>
> Regards
> Brijesh Shukla
>
Thanks,
Aleksey
^ permalink raw reply [flat|nested] 27+ messages in thread
* remote debugging
@ 2003-03-20 7:45 Patricia Alba
0 siblings, 0 replies; 27+ messages in thread
From: Patricia Alba @ 2003-03-20 7:45 UTC (permalink / raw)
To: gdb
hi !
i'm using gdb to debug an application on a remote
target (hitachi 16-bit microcontroller). i downloaded
the gdb stub for a different version and ported it to
work on the board i'm using. i'm able to connect, but
the gdb is unstable. it generates a sigtrap exception
for even normal termination of the program. the values
of local variables are also not working correctly.
any pointers on how to go about debugging the
debugger??
Patricia
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
^ permalink raw reply [flat|nested] 27+ messages in thread
* Remote Debugging
@ 2002-12-12 9:29 Tim
2002-12-12 10:30 ` Daniel Jacobowitz
0 siblings, 1 reply; 27+ messages in thread
From: Tim @ 2002-12-12 9:29 UTC (permalink / raw)
To: gdb
I running gdb 5.2-2 and gdbserver. Remotely I'm running kernel 2.4-19.
I compiled gdbserver against uClibc. My app is statically compiled
against glibc 6.
My remote device is an x86 board.
My app is compiled with -ggdb and is not stripped on either the remote
or the host.
I start gdbserver 192.168.0.1:2345 myapp -options on the remote device.
I start gdb on the host and give it the command target remote
192.168.0.2:2345
the remote device shows a connection from my host.
then I give it the command load myapp.
After all this I cannot view any source. The 'l' command returns the
error 'no symbol table loaded' and instructs me to use file.
What am I doing wrong?
thanx!
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Remote Debugging
2002-12-12 9:29 Remote Debugging Tim
@ 2002-12-12 10:30 ` Daniel Jacobowitz
0 siblings, 0 replies; 27+ messages in thread
From: Daniel Jacobowitz @ 2002-12-12 10:30 UTC (permalink / raw)
To: Tim; +Cc: gdb
On Thu, Dec 12, 2002 at 09:29:56AM -0800, Tim wrote:
> I running gdb 5.2-2 and gdbserver. Remotely I'm running kernel 2.4-19.
> I compiled gdbserver against uClibc. My app is statically compiled
> against glibc 6.
>
> My remote device is an x86 board.
>
> My app is compiled with -ggdb and is not stripped on either the remote
> or the host.
>
> I start gdbserver 192.168.0.1:2345 myapp -options on the remote device.
> I start gdb on the host and give it the command target remote
> 192.168.0.2:2345
>
> the remote device shows a connection from my host.
>
> then I give it the command load myapp.
Try skipping this step. You should not use load with gdbserver.
> After all this I cannot view any source. The 'l' command returns the
> error 'no symbol table loaded' and instructs me to use file.
>
> What am I doing wrong?
Also be sure to give GDB the executable before connecting, i.e. "gdb
myapp".
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 27+ messages in thread
* remote debugging
@ 2002-07-22 9:35 Vinayak P Risbud
0 siblings, 0 replies; 27+ messages in thread
From: Vinayak P Risbud @ 2002-07-22 9:35 UTC (permalink / raw)
To: Ecos-Discuss; +Cc: gdb
Hi,
I am trying to use remote debugging using LAN (Tcp/Ip) on
Redboot
What I understood till now is,
1. the main polls net_io_test function during idle
time
2. The function net_io_test checks for
tcp_sock.state == _ESTABLISHED
3. If established, the control calls
net_io_assume_console
to setup debug channel.
But, after this, how the flow goes, I am not able to
trace.
my gdb client on remote PC sends $Hc-1#09 command,
over tcp/ip link.
I am not able to trace, where and how exactly this gdb
command is read and processed (i.e trap is generated ?)
Can any one help in tracing the flow ?
Thanks in advance
Vinayak
^ permalink raw reply [flat|nested] 27+ messages in thread
* remote debugging
@ 2001-01-25 5:27 malar kavi
2001-01-25 11:46 ` J.T. Conklin
0 siblings, 1 reply; 27+ messages in thread
From: malar kavi @ 2001-01-25 5:27 UTC (permalink / raw)
To: gdb
Hi,
There are some subroutines like
getDebugChar,putDebugChar,flash_i_cache,memset,
exceptionhandler used in i386-stub.c.How can i write
these subroutines and link with the program?After
linking how should i start the program in the target
machine?How should i establish serial communication
with the target machine?
I will be really grateful if anybody is able
to get me out of these problems.
Thanking u in advance.
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: remote debugging
2001-01-25 5:27 malar kavi
@ 2001-01-25 11:46 ` J.T. Conklin
0 siblings, 0 replies; 27+ messages in thread
From: J.T. Conklin @ 2001-01-25 11:46 UTC (permalink / raw)
To: malar kavi; +Cc: gdb
>>>>> "malar" == malar kavi <malarkavi@yahoo.com> writes:
malar> There are some subroutines like
malar> getDebugChar,putDebugChar,flash_i_cache,memset,
malar> exceptionhandler used in i386-stub.c.How can i write
malar> these subroutines and link with the program?After
malar> linking how should i start the program in the target
malar> machine?How should i establish serial communication
malar> with the target machine?
malar> I will be really grateful if anybody is able
malar> to get me out of these problems.
malar> Thanking u in advance.
The getDebugChar() and putDebugChar() functions are simple functions
that you have to supply that interface with some i/o device, usually
a serial port. They don't have to be sophisticated. On many of the
targets I've done this on, I've used polled I/O on UART registers.
For the i386-stub, you don't have to worry about flush_i_cache(). On
some processors, you have to flush the instruction (and sometimes the
data) cache before resuming program execution.
Again, memset() is not needed for the i386-stub. If you were using
one of the sparc stubs (sparc-stub.c or sparclet-stub.c), you would
need to provide a memset() which conforms to Standard (ANSI/ISO) C.
This is actually a bug in those stubs. They should provide their
own static implementation, otherwise the user can't put breakpoints
at memset() to find bugs in their own system.
exceptionHandler() is used to install the exception handlers within
the stub in the processor's exception handler table. In many of my
targets I have a static exception handler table, so I don't install
the exception handlers dynamically. You are the best person to know
how you want to do this. The way you allready install exception and/
or interrupt handlers will probably determine how you do the same for
the debugger stub.
The easiest way to establish connection is to add a call to
breakpoint() as soon as your target has initialized enough to do so.
In other words, after you've initialized the hardware to the point
where your debug channel is up and after you've installed the stub's
exception handler. When your program hits the breakpoint() call, it
will enter the stub's handle_exception loop. At that point, you
simply need to connect to the debugger ('target remote /dev/ttyXX').
Once you've managed that, you might want to make things a little more
sophisticated. For example, if you had an interrupt driven i/o driver
you could set things up so the stub was entered as soon as a character
is received. I recommend that you get a basic polled i/o mechanism
working first though.
--jtc
--
J.T. Conklin
RedBack Networks
^ permalink raw reply [flat|nested] 27+ messages in thread
* remote debugging
@ 2001-01-23 22:23 malar kavi
2001-01-24 6:16 ` Fernando Nasser
2001-01-24 10:52 ` J.T. Conklin
0 siblings, 2 replies; 27+ messages in thread
From: malar kavi @ 2001-01-23 22:23 UTC (permalink / raw)
To: gdb
Hi,
tell me something in detail about the stubs used
in
remote debugging with gdb
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: remote debugging
2001-01-23 22:23 malar kavi
@ 2001-01-24 6:16 ` Fernando Nasser
2001-01-24 10:52 ` J.T. Conklin
1 sibling, 0 replies; 27+ messages in thread
From: Fernando Nasser @ 2001-01-24 6:16 UTC (permalink / raw)
To: malar kavi; +Cc: gdb
malar kavi wrote:
>
> Hi,
> tell me something in detail about the stubs used
> in
> remote debugging with gdb
>
It is in the manual.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: remote debugging
2001-01-23 22:23 malar kavi
2001-01-24 6:16 ` Fernando Nasser
@ 2001-01-24 10:52 ` J.T. Conklin
1 sibling, 0 replies; 27+ messages in thread
From: J.T. Conklin @ 2001-01-24 10:52 UTC (permalink / raw)
To: malar kavi; +Cc: gdb
>>>>> "malar" == malar kavi <malarkavi@yahoo.com> writes:
malar> Hi, tell me something in detail about the stubs used in remote
malar> debugging with gdb
As Fernando mentioned, how to integrate/use the sample stubs is
described in the manual. If after reading that section you still have
specific questions, don't hesitate to ask them. We'll do our best to
answer them, as well as improve the manual to make it clearer.
--jtc
--
J.T. Conklin
RedBack Networks
^ permalink raw reply [flat|nested] 27+ messages in thread
* Remote Debugging
@ 2000-11-30 22:27 Yu Xuanwei
2000-12-01 11:40 ` Fernando Nasser
0 siblings, 1 reply; 27+ messages in thread
From: Yu Xuanwei @ 2000-11-30 22:27 UTC (permalink / raw)
To: gdb
Hi, Folks:
I am a rookie. I want to know something about remote debugging:
1. On target: The gdbserver manipulates target application, which is
stripped.
2. On host: GDB run "target remote ..." to customize the target.
Then where is the symbol file for target application? Should I native
compile the target application on host? Or ...?
Sincerely,
Kenny Yu
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Remote Debugging
2000-11-30 22:27 Remote Debugging Yu Xuanwei
@ 2000-12-01 11:40 ` Fernando Nasser
0 siblings, 0 replies; 27+ messages in thread
From: Fernando Nasser @ 2000-12-01 11:40 UTC (permalink / raw)
To: Yu Xuanwei; +Cc: gdb
Yu Xuanwei wrote:
>
> Hi, Folks:
>
> I am a rookie. I want to know something about remote debugging:
>
> 1. On target: The gdbserver manipulates target application, which is
> stripped.
>
> 2. On host: GDB run "target remote ..." to customize the target.
>
> Then where is the symbol file for target application? Should I native
> compile the target application on host? Or ...?
>
Nope. You cross compile your executable with "-g". Create a stripped copy
(not necessary if you don't care about file sizes in the target) and copy
the stripped version to the target. Load it with gdbserver.
On the host side: gdb <your-complete-executable-with-debug-info>
and proceed as you mentioned.
But please, before you try to go any further, print a copy of the
"Debugging with GDB" manual. It is in the doc directory (you can make it in
various flavors - ps among them). It is also available as an info topic
if GDB is correctly installed on your system.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
^ permalink raw reply [flat|nested] 27+ messages in thread
* Remote Debugging
@ 2000-11-29 19:52 Yu Xuanwei
0 siblings, 0 replies; 27+ messages in thread
From: Yu Xuanwei @ 2000-11-29 19:52 UTC (permalink / raw)
To: gdb
Hi, buddies:
I've scanned all gdb mailist archives and gdb manual. I'm still
confused.
What I 've done:
1. cross-compile gdbserver by m68k-pic-coff compiler.
2. Download gdbserver into M68EZ328 ADS board.
3. Run it as: EZ328> gdbserver MyHost:port test, (test is stripped).
4. Native compile(Intel) in host: gcc -g test.c -o htest, (test.c is
just a HelloWorld)
5. Run gdb in Intel host: MyHost> gdb
gdb> target remote EZ328:port
gdb> symbol-file htest
gdb> b main
gdb> c
gdb> n
.
.
.
gdb> Program exit normally
6. See 'Hello World!' in target screen, and the gdbserver end when the
gdb session is over.
Idoubt whether I was right. I don't know how to 'load'. I don't know how
to prevent gdbserver exiting after one gdb session. I don't understand
whether I got the exact case in target via TCP. I feel unconfident.
Thanks a lot,
Yu Xuanwei
^ permalink raw reply [flat|nested] 27+ messages in thread
* Remote debugging
@ 2000-11-28 0:59 Yu Xuanwei
0 siblings, 0 replies; 27+ messages in thread
From: Yu Xuanwei @ 2000-11-28 0:59 UTC (permalink / raw)
To: gdb
Hi, buddies:
I've scanned all gdb mailist archives and gdb manual. I'm still
confused.
What I 've done:
1. cross-compile gdbserver by m68k-pic-coff compiler.
2. Download gdbserver into M68EZ328 ADS board.
3. Run it as: EZ328> gdbserver MyHost:port test, (test is stripped).
4. Native compile(Intel) in host: gcc -g test.c -o htest, (test.c is
just a HelloWorld)
5. Run gdb in Intel host: MyHost> gdb
gdb> target remote EZ328:port
gdb> symbol-file htest
gdb> b main
gdb> c
gdb> n
.
.
.
gdb> Program exit normally
6. See 'Hello World!' in target screen, and the gdbserver end when the
gdb session is over.
Idoubt whether I was right. I don't know how to 'load'. I don't know how
to prevent gdbserver exiting after one gdb session. I don't understand
whether I got the exact case in target via TCP. I feel unconfident.
Thanks a lot,
Yu Xuanwei
^ permalink raw reply [flat|nested] 27+ messages in thread
* remote debugging
@ 2000-08-15 10:13 Shaun Jackman
2000-08-15 12:23 ` Fernando Nasser
0 siblings, 1 reply; 27+ messages in thread
From: Shaun Jackman @ 2000-08-15 10:13 UTC (permalink / raw)
To: gdb list
What is the preferred method for remote debugging?
I have an Atmel EB01, AT91M40400 processor (ARM7TDMI) which came with an
Angel monitor in flash.
Debugging with it is dead slow. Stepping through a few lines of code which
occurs as fast as I can click in the simulator takes ~20 seconds with the
Angel monitor. Also, I am unable to connect to the Angel monitor faster than
9600 (although I can go up to 38400 with the Arm Ltd. debugger).
I have a Jeeni on loan (JTAG Angel over ethernet) which allows me to debug
as fast as the simulator, but they're bloody expensive! I'd prefer a serial
or parallel solution if possible, only for cost reasons. (unless someone
knows of a cheap ethernet device!)
Is serial-tether debugging necessarily as slow as the Angel monitor? Would
Cygmon or the gdb-stub be better?
My preferred development environment would be Linux, but I'm stuck in a
dual-booting limbo right now until I can sort out my tool-chain problems.
Many thanks,
Shaun Jackman
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: remote debugging
2000-08-15 10:13 remote debugging Shaun Jackman
@ 2000-08-15 12:23 ` Fernando Nasser
0 siblings, 0 replies; 27+ messages in thread
From: Fernando Nasser @ 2000-08-15 12:23 UTC (permalink / raw)
To: Shaun Jackman; +Cc: gdb list
Shaun Jackman wrote:
>
> What is the preferred method for remote debugging?
>
> I have an Atmel EB01, AT91M40400 processor (ARM7TDMI) which came with an
> Angel monitor in flash.
> Debugging with it is dead slow. Stepping through a few lines of code which
> occurs as fast as I can click in the simulator takes ~20 seconds with the
> Angel monitor. Also, I am unable to connect to the Angel monitor faster than
> 9600 (although I can go up to 38400 with the Arm Ltd. debugger).
>
gdb 5.0 should be able to talk to RDI targets up to 115200. Of course
it depends
on the board you have. On a board I have with a StrongARM processor I
can talk
to Angel at 115200 but on the ARM Inc. $150 AEB board I can only connect
at 9600.
The protocol is very simple: gdb (actually, the code ARM gave us), using
9600 bauds,
proposes the speeds it can handle starting with the preferred one,
115200 of course,
and the board replies with the speed it can handle. The AEB board
replies with 9600,
so gdb uses 9600 and things are slow as you say.
But there is not much we can do about this. We cannot just ignore the
Angel monitor
reply because the board must switch to the appropriate speed after the
reply (and that
is the protocol, damn it!)
> I have a Jeeni on loan (JTAG Angel over ethernet) which allows me to debug
> as fast as the simulator, but they're bloody expensive! I'd prefer a serial
> or parallel solution if possible, only for cost reasons. (unless someone
> knows of a cheap ethernet device!)
>
> Is serial-tether debugging necessarily as slow as the Angel monitor? Would
> Cygmon or the gdb-stub be better?
>
Cygmon is nice. It works fast at 115200 speed but it is only available
for some
boards. You will have to check with your board manufacturer.
> My preferred development environment would be Linux, but I'm stuck in a
> dual-booting limbo right now until I can sort out my tool-chain problems.
>
There was a problem, at some point, with the gdb RDI protocol (the one
used to
talk to Angel) on CygWin some time ago. It works fine now, so if you
get a
recent CygWin dll you should be able to use it on a Window box.
--
Fernando Nasser
Red Hat Canada Ltd.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Remote Debugging
@ 2000-04-01 0:00 Timo Ketola
2000-02-23 19:12 ` Andrew Cagney
0 siblings, 1 reply; 27+ messages in thread
From: Timo Ketola @ 2000-04-01 0:00 UTC (permalink / raw)
To: gdb
Hi all,
I just subscribed to this list...
I'm adapting the gdb and the remote stub for our embedded system.
Debugging works already over a RS232 line but I have a couple of
questions for which I can't find an answer:
1) I want to be able to debug also over a CAN network. I think I have to
write a new interface for the gdb. Namely the getpkt and putpkt of the
remote.c should be reimplemented. But what is a clean way? Could someone
assist me a bit.
2) When I 'load' a new executable into the target the loading works well
but the symbols are not loaded. At the end of generic_load function
comment asks whether symbol_file_add function should be called. Is that
exactly the right thing to do?
3) How do I get a clean information about the load of the new executable
in the stub? Before a new executable is started (or an old one
restarted) the stub needs to do a couple of things (for example clean up
the stack).
Please, forgive me if the answers are too obvious...
--
Timo
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Remote Debugging
2000-04-01 0:00 Remote Debugging Timo Ketola
@ 2000-02-23 19:12 ` Andrew Cagney
2000-04-01 0:00 ` Andrew Cagney
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Cagney @ 2000-02-23 19:12 UTC (permalink / raw)
To: Timo Ketola; +Cc: gdb
Timo Ketola wrote:
>
> Hi all,
>
> I just subscribed to this list...
>
> I'm adapting the gdb and the remote stub for our embedded system.
> Debugging works already over a RS232 line but I have a couple of
> questions for which I can't find an answer:
>
> 1) I want to be able to debug also over a CAN network. I think I have to
> write a new interface for the gdb. Namely the getpkt and putpkt of the
> remote.c should be reimplemented. But what is a clean way? Could someone
> assist me a bit.
A alternative might be to modify gdbserver (or the like) and use GDB's
remote protocol (target extended-remote). (I'm not sure what a CAN
network is).
> 2) When I 'load' a new executable into the target the loading works well
> but the symbols are not loaded. At the end of generic_load function
> comment asks whether symbol_file_add function should be called. Is that
> exactly the right thing to do?
Are you loading different files or the same file?
(gdb) file foo.out
(gdb) target .....
(gdb) load
both loads the file and updates the symbols. There are also commands
for loading symbols from a specific file.
> 3) How do I get a clean information about the load of the new executable
> in the stub? Before a new executable is started (or an old one
> restarted) the stub needs to do a couple of things (for example clean up
> the stack).
I've seen this done two ways:
o the embedded equivalent of crt0.o
initialises the stack (and zero's
bss)
o *_create_inferior() performs
the initialize operation.
(see remote-sim.c)
enjoy,
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Remote Debugging
2000-02-23 19:12 ` Andrew Cagney
@ 2000-04-01 0:00 ` Andrew Cagney
0 siblings, 0 replies; 27+ messages in thread
From: Andrew Cagney @ 2000-04-01 0:00 UTC (permalink / raw)
To: Timo Ketola; +Cc: gdb
Timo Ketola wrote:
>
> Hi all,
>
> I just subscribed to this list...
>
> I'm adapting the gdb and the remote stub for our embedded system.
> Debugging works already over a RS232 line but I have a couple of
> questions for which I can't find an answer:
>
> 1) I want to be able to debug also over a CAN network. I think I have to
> write a new interface for the gdb. Namely the getpkt and putpkt of the
> remote.c should be reimplemented. But what is a clean way? Could someone
> assist me a bit.
A alternative might be to modify gdbserver (or the like) and use GDB's
remote protocol (target extended-remote). (I'm not sure what a CAN
network is).
> 2) When I 'load' a new executable into the target the loading works well
> but the symbols are not loaded. At the end of generic_load function
> comment asks whether symbol_file_add function should be called. Is that
> exactly the right thing to do?
Are you loading different files or the same file?
(gdb) file foo.out
(gdb) target .....
(gdb) load
both loads the file and updates the symbols. There are also commands
for loading symbols from a specific file.
> 3) How do I get a clean information about the load of the new executable
> in the stub? Before a new executable is started (or an old one
> restarted) the stub needs to do a couple of things (for example clean up
> the stack).
I've seen this done two ways:
o the embedded equivalent of crt0.o
initialises the stack (and zero's
bss)
o *_create_inferior() performs
the initialize operation.
(see remote-sim.c)
enjoy,
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2015-03-08 7:48 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-13 14:24 remote debugging nak26
-- strict thread matches above, loose matches on Subject: below --
2015-03-07 13:52 Remote debugging Russell Shaw
2015-03-07 14:09 ` Ofir Cohen
2015-03-08 7:48 ` Russell Shaw
2004-03-22 14:23 luca risso
2004-03-19 17:59 luca risso
2004-03-19 18:43 ` Daniel Jacobowitz
2003-06-13 7:50 remote debugging Brijesh Shukla
2003-06-13 13:28 ` Quality Quorum
2003-03-20 7:45 Patricia Alba
2002-12-12 9:29 Remote Debugging Tim
2002-12-12 10:30 ` Daniel Jacobowitz
2002-07-22 9:35 remote debugging Vinayak P Risbud
2001-01-25 5:27 malar kavi
2001-01-25 11:46 ` J.T. Conklin
2001-01-23 22:23 malar kavi
2001-01-24 6:16 ` Fernando Nasser
2001-01-24 10:52 ` J.T. Conklin
2000-11-30 22:27 Remote Debugging Yu Xuanwei
2000-12-01 11:40 ` Fernando Nasser
2000-11-29 19:52 Yu Xuanwei
2000-11-28 0:59 Remote debugging Yu Xuanwei
2000-08-15 10:13 remote debugging Shaun Jackman
2000-08-15 12:23 ` Fernando Nasser
2000-04-01 0:00 Remote Debugging Timo Ketola
2000-02-23 19:12 ` Andrew Cagney
2000-04-01 0:00 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).