Date: Sun, 1 Sep 1996 05:34:30 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, julian@whistle.com Cc: hackers@FreeBSD.org, pst@shockwave.com Subject: Re: gdb remote Message-ID: <199608311934.FAA04223@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
I wrote: >Yes, I have a much better version :-). First try only the CFCR_8BITS >change out of it. Writing the speed to the same value should by harmless. >(Make sure that the port is set to the default speed by stty'ing it in >the usual way if necessary. The defaults are 9600 for everything.) My problems were mostly caused by not changing the other occurrence of CFCR_8BITS and forgetting to open /dev/cuaa0 after stty'ing /dev/cuaia0. I have something in /etc/rc.serial that sets the speed to 115200. >I think I understand the problem now. Sio console output is unbuffered >except for fifos in the hardware, so input is guaranteed to be lost if >... >of size 400. I'm writing some buffering routines now. The buffering didn't seem to help much. The protocol seems to be very non-robust. gdb dumped core once and reported `invalid digit in hex character' several times, and the remote often stopped responding. Now my problem is that gdb-4.13 can't handle its own breakpoints. `b pcaopen' seems to put a breakpoint at the reasonable place pcaopen+3. Then when the breakpoint is hit, it isn't removed, and the pc is pcaopen+4. Then disassembling at pcaopen causes a fatal page fault at address 0x55. >! outb(iobase + com_cfcr, CFCR_DLAB | CFCR_8BITS); >--- 2493,2503 ---- > * Restore the device control registers. > */ > siocntxwait(); > iobase = siocniobase; > outb(iobase + com_cfcr, CFCR_DLAB); Change this like the above. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608311934.FAA04223>