Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Mar 1997 15:53:12 -0500
From:      Bakul Shah <bakul@torrentnet.com>
To:        hackers@freebsd.org
Subject:   kernel remote debugging using gdb
Message-ID:  <199703142053.PAA00554@chai.plexuscom.com>

next in thread | raw e-mail | index | archive | help
This seems to work mostly but there are a few problems.

What I did:

- recompiled the boot program to always use COM1 as console and
  installed it on the primary disk on the test machine (called TEST).

- used the following options in the TEST config file:
    options         COMCONSOLE
    options         DDB
    options         BREAK_TO_DEBUGGER

- config -g TEST and compiled the test kernel on the development
  machine (called DEVEL), and copied it to TEST.

- connected TEST's COM1 to DEVEL's COM2 with a `null modem' cable.

- started kermit on DEVEL and connected to TEST @ 9600 baud

- rebooted TEST.  When the boot prompt came up in the kermit window,
  booted the kernel single-user.

- once the kernel came up I hit ^\b in kermit to send a break to TEST.
  When DDB gained control I typed gdb so that on the next trap it
  will start the gdb remote protocol.  I continued the kernel and
  then I sent another break and the TEST kernel did spew out out gdb
  remote stuff (which has a distinctive pattern).

- Next I stopped kermit on DEVEL and chdir'ed to $SRC/sys/compile/TEST
  and started gdb.

- in gdb I typed
    file kernel
    target remote /dev/cuaa1

At this point gdb starts controlling the remote kernel.  Now one can
add breakpoints, examine variables and so on.  

There are two problems:

- Sendind a break in multiuser mode (before or after attaching gdb)
  does not seem to drop the kernel in the debugger.  This seems to
  work occasionally but I haven't as yet figured out under what
  conditions.

- In single user mode when gdb is attached, you can not type anything
  on the console nor can you see any printf() output[1].


These problems make debugging the kernel with gdb somewhat
challenging.  Am I doing something wrong or missing a crucial step?
If these problems can be solved may be the above description can be
added to the handbook or the FAQ.

I am debugging a 2.2-961006-SNAP, if it matters.  Thanks for any
help!  Any other hints/ideas on making this process less tedious are
also more than welcome.

-- bakul

[1] Note that passing console device IO `through gdb' would be
    extremely useful as it will feel as if gdb is built in.  Not
    sure if this works at all for the standard gdb remote protocol.
    At any rate adding it would not be hard.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703142053.PAA00554>