This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Remote Debugging
- To: Timo Ketola <Timo dot Ketola at Epec dot fi>
- Subject: Re: Remote Debugging
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 24 Feb 2000 14:10:39 +1100
- CC: gdb at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <38B4017A.2F64A9C3@Epec.fi>
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