From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Timo Ketola Cc: gdb@sourceware.cygnus.com Subject: Re: Remote Debugging Date: Wed, 23 Feb 2000 19:12:00 -0000 Message-id: <38B4A12F.C3BE09F1@cygnus.com> References: <38B4017A.2F64A9C3@Epec.fi> X-SW-Source: 2000-02/msg00000.html 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 To: Franz Sirl , 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> 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 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> 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 To: Kevin Buettner 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: <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.