[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: gdb remote
From:       Bruce Evans <bde () zeta ! org ! au>
Date:       1996-08-31 19:34:30
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]