Date: Wed, 26 Apr 2000 08:31:07 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Greg Lehey <grog@lemis.com> Cc: FreeBSD Committers <cvs-committers@freebsd.org>, FreeBSD current users <FreeBSD-current@freebsd.org> Subject: Re: Remote serial gdb is broken in -CURRENT. Message-ID: <Pine.BSF.4.21.0004260828300.79607-100000@salmon.nlsystems.com> In-Reply-To: <20000426105344.B38665@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Apr 2000, Greg Lehey wrote: > On Tuesday, 25 April 2000 at 9:39:10 +0100, Doug Rabson wrote: > > On Tue, 25 Apr 2000, Greg Lehey wrote: > > > >> On Sunday, 23 April 2000 at 10:07:38 +0100, Doug Rabson wrote: > >>> On Sun, 23 Apr 2000, Greg Lehey wrote: > >>> > >>>> In the last few days, my remote serial gdb has almost completely > >>>> stopped working. Previously I had (almost) no trouble at 38400 bps; > >>>> now I can barely get a response at all at 9600 bps. Does anybody have > >>>> an idea where this could be coming from? > >>> > >>> I noticed this too but I have no idea why. I also had to move back to > >>> 9600. > >> > >> I've found the problem and fixed it. It's been broken all along, but > >> for some reason it got worse lately. > >> > >> Basically, what happened was that the getpacket function, which does > >> polled I/O, wasn't locking out interrupts, and something was > >> interrupting long enough for characters to get lost. Since sometimes > >> several consecutive characters got lost, it seems likely that either > >> something locks out interrupts for an inappropriately long time, or > >> the sio interrupt routines steal them. Anyway, it works nicely at > >> 115200 bps now. > > > > Great, thanks Greg. Debugging at 9600bps was getting painful :-) > > Even that didn't work for me. BTW, the fix had the side effect of > making the clock stand still. I've changed the code (spltty instead > of splhigh), and it seems to work OK now, so it probably was the tty > interrupt stealing characters. I'll commit when I'm sure all is still > OK. Cool. > > > On a nearly unrelated subject, can you try out the new stuff I just put > > into the kernel linker to allow it to export information to GDB. Now you > > should be able to use GDB's "sharedlibrary" command to load symbols. Make > > sure that the path used to load the file on the debugged machine is a > > valid path leading to the same file on the debugger machine. > > This looks like just what I'm looking for, especially if it can > extract kld symbols. How do I use it? Basically, all you do is load the module on the scratch box. Use an absolute path which also leads to the same file on the debugging box. Then break into GDB somehow and type "sharedlibrary". The debugger should print a message about each file which it finds and you can then use "info sharedlibrary" to see where they were loaded. All the symbols are loaded and relocated properly so you should be able to set breakpoints etc. as normal. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0004260828300.79607-100000>