Re: Remote Debugging

[Andrew Cagney <ac131313@cygnus.com>]

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
From kevinb@cygnus.com Thu Feb 24 01:52:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>, gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Thu, 24 Feb 2000 01:52:00 -0000
Message-id: <1000224095244.ZM13976@ocotillo.lan>
References: <1000222025201.ZM9805@ocotillo.lan> <00022300073001.01275@enzo.bigblue.local> <Franz.Sirl-kernel@lauterbach.com>
X-SW-Source: 2000-02/msg00001.html
Content-length: 890

On Feb 22, 11:09pm, Franz Sirl wrote:

> >I invite those of you who have Linux/PPC machines to try out these
> >changes and let me know how they work.  Also, please let me know about
> >any problems that you find.
> 
> I've just uploaded an RPM with the current CVS source to
> ftp://devel.linuxppc.org/users/fsirl/ so people can easily test it.

Thanks.

[...]
> A quick test of gdb looked very promising, I already installed it as the
> default gdb on our build system. What about "info float"? Are you going to
> tackle this yourself later or do you want to leave the implementation to
> somebody else?

If someone else is willing to do the implementation for "info float",
I'm willing to integrate the patches.  (I rarely have need for "info
float", so it may be better if someone else did the implementation.)
OTOH, if no one sends me patches, I'll try to get to it eventually.

Kevin
From kevinb@cygnus.com Thu Feb 24 02:12:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: khendricks@ivey.uwo.ca
Cc: gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Thu, 24 Feb 2000 02:12:00 -0000
Message-id: <1000224101226.ZM14012@ocotillo.lan>
References: <1000222025201.ZM9805@ocotillo.lan> <00022300073001.01275@enzo.bigblue.local> <00022221542500.09439@localhost.localdomain> <khendricks@ivey.uwo.ca>
X-SW-Source: 2000-02/msg00002.html
Content-length: 1901

On Feb 22,  9:49pm, Kevin Hendricks wrote:

> Here is my first bug report.  This is with gdb from today's cvs
> (after your later commit) debugging a problem with Motif Drag-n-Drop
> in the jdk under native threads.
>
> Everything was working fine until I decided to rerun the program
> from within gdb without removing my shared library breakpoints
> first.

Does it work if you disable your shared library breakpoints first?

> Here is the resulting log file.  Notice the non-existent breakpoint
> 0 and also even through I manually removed all of my breakpoints and
> tried to continue I could not do so.
> 
> I hope this info helps.  The only simple test case would be to
> actually run the DDTest java program under the jdk with Motif source
> around.
> 
> Let me know if you would like more info about this bug (explicit
> steps to try) and I would be happy to follow instructions.

I've seen this problem before on other platforms.  It would really be
nice to have a relatively small test case to debug this problem with. 
Do you think you could whittle the problem down to something that you
could send us the source to?  

It'd also be nice to incorporate such a test into the test suite.  If
you can provide me with a C program which exhibits the problem, I'll
work on the expect script to incorporate it into the test suite.  (I'll
also work on tracking down the bug and fixing it.)  Remember that we'll
need copyright assignments for anything that winds up in the test suite.

You may (or may not) find it useful to start with the shared library
tests already in the test suite.  Take a look in gdb/testsuite/gdb.base
at the files shmain.c, shr1.c, and shr2.c.

BTW, I just fixed one of the bugs (there were actually two separate bugs)
which was causing one of the shared library tests to fail.  I'll commit
this fix later on today, but I doubt it will solve your problem.

Thanks,

Kevin
From Franz.Sirl-kernel@lauterbach.com Thu Feb 24 02:22:00 2000
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Thu, 24 Feb 2000 02:22:00 -0000
Message-id: <4.2.2.20000224111642.04d2f430@mail.lauterbach.com>
References: <Franz.Sirl-kernel@lauterbach.com> <1000222025201.ZM9805@ocotillo.lan> <00022300073001.01275@enzo.bigblue.local> <1000224095244.ZM13976@ocotillo.lan>
X-SW-Source: 2000-02/msg00003.html
Content-length: 728

At 10:52 24.02.00 , Kevin Buettner wrote:
> > A quick test of gdb looked very promising, I already installed it as the
> > default gdb on our build system. What about "info float"? Are you going to
> > tackle this yourself later or do you want to leave the implementation to
> > somebody else?
>
>If someone else is willing to do the implementation for "info float",
>I'm willing to integrate the patches.  (I rarely have need for "info
>float", so it may be better if someone else did the implementation.)
>OTOH, if no one sends me patches, I'll try to get to it eventually.

Ok, I just wanted to clear the status of "info float", I'll take a look at 
it too and maybe I should already think about "info vector" :-)).

Franz.