public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: linux-kernel@vger.kernel.org
Subject: kgdb with sw single-step...
Date: Tue, 29 Apr 2008 01:02:21 -0700 (PDT)	[thread overview]
Message-ID: <20080429.010221.268320653.davem@davemloft.net> (raw)


While working on the sparc port of the new kgdb code in the tree I ran
across a fundamental issue with this stuff on cpus that do
single-stepping in software.

The short story is that since such sw single-stepping is using
globally visible state (the temporary breakpoint used), it does not
fare well in the presence of cpus other than the current one hitting
the single-step breakpoint.

This actually limits my ability to test using kgdbts fully, the
parallel tests often fail because the sw single-step emulation
in kgdbts runs into several issues including the one I'm
mentioning here.

The good news is that there is a mostly working solution possible.

When GDB is handling a normal threaded process, it handles other
threads tripping over the temporary single-step breakpoint by simply
holding them stopped until the thread that should have hit the
breakpoint, does hit it.

The kernel could do something similar, but this would require
something like:

1) The architecture kgdb support code implements the sw single
   step breakpoint logic, this is necessary in order to
   handle single stepping over branches, calls, and things
   of this nature.  (this is something the single-step
   emulation code in kgdbts doesn't even try to get right).

2) The kgdb stub implements the single-stepping command using
   the support code in #1.  When this happens, foreign cpus
   which have been captured are kept captured until the
   single-step breakpoint it hit by the primary kgdb cpu.

Of course, this means we'll need changes to how gdb talks over the
stub on these processors (mips, arm, sparc, etc.)  since currently gdb
will do all of the sw single-step breakpoint work.

Some architectures, like Alpha, do the single-stepping in the
ptrace implementation.  Basically it's doing all of the sw
single-step breakpoint work on the kernel side, instead of
in gdb.  Platforms like Alpha would therefore be readily adaptable
to the above scheme without any gdb changes.


             reply	other threads:[~2008-04-29  8:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-29  8:02 David Miller [this message]
2008-04-29 15:01 ` kgdb with sw single-step Jason Wessel
2008-04-29 22:35   ` David Miller

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=20080429.010221.268320653.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.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