kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: mobile.parmenides@gmail.com (Parmenides)
To: kernelnewbies@lists.kernelnewbies.org
Subject: How to debug a kernel thread?
Date: Fri, 30 Mar 2012 20:00:59 +0800	[thread overview]
Message-ID: <CAOXENUgjwc6bHoPDizfjX3x6hUsLA_Ejsijw3Mqs=aizKe7wVw@mail.gmail.com> (raw)

Hi,

  It is said that the kernel can be debugged in qemu and I take a
try. First, I started the qemu with

                 qemu -m 64M -kernel arch/x86/boot/bzImage -initrd
~/image.cpio.gz  -net nic -net tap,ifname=tap0  -s

 In another console

                  gdb vmlinux
                  (gdb) target remote localhost:1234
                  (gdb) continue

A LKM (mymodule.ko) which starts a kernel thread is made with debug
info, and was 'scp' to the guest. In guest, it is inserted by

                  insmod mymodule.ko

Then, back to gdb

                  (gdb) add-symbol-file mymodule.ko 0xc482e000
                  (gdb) break mymodules.c:37
                  (gdb) continue

The 37th line of mymodules.c is in a loop of kernel thread, which
ensures the breakpoint should be triggered every time the loop go
through.  But, the breakpoint doesn't triggered as expected. Instead,
the kernel thread is running over and over indicated by its repeated
output messages. So, I think a kernel thread can not be break by any
breakpoint.

However, I think maybe the gdb want to attach to the kernel thread.
Then, I checked the kernel thread's PID with ps and got 62.

                 (gdb) control+C
                 (gdb) attach 62

The gdb promted me it will kill the program being debugged. I answered
with 'yes', the gdb told me

                 ptrace: No such process.

then the debug session is terminated and the guest is closed.

I started the qemu  with the above command again

                 qemu -m 64M -kernel arch/x86/boot/bzImage -initrd
~/image.cpio.gz  -net nic -net tap,ifname=tap0  -s

And, without quitting the gdb

                  (gdb) target remote localhost:1234
                  (gdb) continue

In the guest, 'mymodule.ko' is inserted again

                  insmod mymodule.ko

I found that the breakpoint set at mymodule.c:37 is triggered this
time surprisingly, and the 'insmod' didn't return immediately until
the gdb is given with another 'continue' command.

                  (gdb) continue

Then, the breakpoint doesn't triggered anymore as usual,


There is two questions:

1. Why the kernel thread can not be break?
2. Why is the breakpoint triggered just when the 'mymodule.ko' is loaded?

Thanks.

             reply	other threads:[~2012-03-30 12:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-30 12:00 Parmenides [this message]
2012-03-30 14:48 ` How to debug a kernel thread? Mulyadi Santosa
     [not found]   ` <CAOXENUj9F6qHEzcmqRbmoLOan0ivWuer3-vuWqcpA8nuqkyMOQ@mail.gmail.com>
2012-04-03 16:00     ` Mulyadi Santosa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOXENUgjwc6bHoPDizfjX3x6hUsLA_Ejsijw3Mqs=aizKe7wVw@mail.gmail.com' \
    --to=mobile.parmenides@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).