remote debugging

remote debugging

[malar kavi]

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/

Re: remote debugging

[Fernando Nasser]

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

Re: remote debugging

[J.T. Conklin]

>>>>> "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

Remote debugging

[Russell Shaw]

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?

Re: Remote debugging

[Ofir Cohen]

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?

Re: Remote debugging

[Russell Shaw]

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.

Re: Remote debugging

[luca risso]

>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

Remote debugging

[luca risso]

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/

Re: Remote debugging

[Daniel Jacobowitz]

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

RE: remote debugging

[nak26]

>>  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

remote debugging

[Brijesh Shukla]

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

Re: remote debugging

[Quality Quorum]

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

remote debugging

[Patricia Alba]

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

Remote Debugging

[Tim]

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!

Re: Remote Debugging

[Daniel Jacobowitz]

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

remote debugging

[Vinayak P Risbud]

        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

remote debugging

[malar kavi]

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/

Re: remote debugging

[J.T. Conklin]

>>>>> "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

Remote Debugging

[Yu Xuanwei]

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

Re: Remote Debugging

[Fernando Nasser]

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

Remote Debugging

[Yu Xuanwei]

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

Remote debugging

[Yu Xuanwei]

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

remote debugging

[Shaun Jackman]

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

Re: remote debugging

[Fernando Nasser]

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.

Remote Debugging

[Timo Ketola]

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

Re: Remote Debugging

[Andrew Cagney]

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

Re: Remote Debugging

[Andrew Cagney]

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