From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Timo Ketola <Timo.Ketola@Epec.fi>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Remote Debugging
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-ID: <38B4A12F.C3BE09F1@cygnus.com>
References: <38B4017A.2F64A9C3@Epec.fi>
X-SW-Source: 2000-q1/msg00394.html
Message-ID: <20000401000000.KgQUYxaqS658YawiQY57cdhnCMqhVNnXfsfqaM4J7MQ@z>

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