Thanks! I'm closer now, but having problems (see below).

At 01:20 AM 12/6/99 -0500, Ken Hornstein wrote:
>I keep meaning to write a web page, but a really short tutorial would be:
>
>- Copy the kernel to the machine where you're running gdb (the
>  unstripped one with all of the symbols ... you will know which one,
>  because it will be gigantic)
>- Run gdb on that kernel, and set the breakpoints you're interested in.
>- "boot -d" with the stripped kernel on the target machine.
>- Use the "remote" command to attach to it when the machine stops (it
>  prints a message during the boot process saying, "Waiting for debugger",
>  or something similar).

Digging in the info pages, it looks like the command (using com0/tty00 on
the remote) would be:

	target remote /dev/tty00

On my machines, at least, both ends end up just waiting for each other
forever. If I boot the target without -d, I do see the message that com0 is
on isa0 at 0x3f8, irq4, followed by "com0: gsb", and if I boot with a
non-GDB-enabled kernel and run tip to tty00, I see the following stuff on
the screen of the target machine when I give the "target" command above to
gdb on the remote machine:

	+$Hc-1#09

I don't know if that's a reasonable command or not (I couldn't find
anything about an "H" command), but at least the delimiters look
reasonable, so the baudrate, cables, etc are correct.

So, what could be causing the two ends to not want to talk to each other?
The target machine is a laptop (Thinkpad 600) and the serial port is
software-configurable, so I suppose it could be that the gdb connect is so
early in the startup that it hasn't yet been configured. On the other hand,
it is probed "at isa", not "at isapnp", so it would seem that isn't the case.

Any other ideas? Has anyone run gdb on a kernel lately?

My next step (after some sleep!) is to switch the remote and target
machines and see if it's any better.