[Top] [All Lists]

SMP patches for kdb

To: kdb@xxxxxxxxxxx
Subject: SMP patches for kdb
From: Ethan Solomita <ethan@xxxxxxxxxxxxxxx>
Date: Thu, 02 May 2002 00:43:15 -0700
Sender: owner-kdb@xxxxxxxxxxx
        It took a little longer than I'd thought, but I think I've got a
reasonable shot at a patch that fixes SMP stuff. The catch -- I haven't
made the i386-specific changes, just the sparc64 changes, but I don't
think they'll be devastatingly complicated or anything.

        I've attached a .tar.bz2 (<10K) with three text files. One is a patch
to the common code relative to kdb-v2.1-2.4.18-common-3. One is a diff
to sparc64's kdba_bp.c relative to sparc64-common-2. The third is
kdba_bp.c in its entirety, to make it easier to see what needs to change
in i386.

        I've put these together in a bit of a hurry before a short vacation, so
I hope I haven't messed up the patches. The changes aren't small, so let
me try to explain/justify.

        I wouldn't say that kdb() has been rewritten, since I didn't write much
new code. But it has been heavily reordered to make sure that no state
(eg. KDB_STATE) is modified until someone has won the race to
kdb_initial_cpu. This'll make it hard to follow the changes to kdb()
from the diffs.

        I spent a lot of time getting the breakpoints to work correctly -- it
was more involved than I'd expected. Most importantly, after hitting a
breakpoint and then saying "go", I had to make sure that the other CPUs
aren't released from kdb until kdb_initial_cpu has finished
single-stepping and restoring the breakpoints.

        To do this, I changed kdb to treat this as a variant on a standard
single-step request. I eliminated the complicated thing with breakpoints
having a "delay" and "delayed" field to mark this progress. If we need
to do the single-step game after a "go", I set a state flag "NEED_SSBPT"
instead of setting the "delay" field of a breakpoint.

        If we then say "go" with that state set, I set DOING_SS and DOING_SSBPT
in combination. It then proceeds to do a standard single-step, ie. it
doesn't release the other CPUs.

        I had to change kdb_main_loop() so that it doesn't actually release the
other CPUs (that's moved into kdb()), and also that a "go" is always
handled by kdb_initial_cpu, even if you've switched to another cpu. So
if you say "go", it will magically switch to kdb_initial_cpu and then do
the "go".

        For whoever wants to tackle i386, some notes: The sparc64
kdba_db_trap() is simpler than the i386 version, because sparc64 doesn't
have hardware watchpoint or breakpoint support. It also doesn't have
hardware single-step support, although that's another story.

        So the i386 kdba_db_trap() should change similarly to the sparc64
version, but you just have to ignore all of its code that doesn't exist
in sparc64. Most of the other changes in the file are simple.

        I hope that this all makes sense -- and that it works. 8-) I tested
with a breakpoint that is hit in parallel on two processors, I tested
single-stepping and going after switching the processor, etc. But I'm
sure it's not perfect, so the more people that take a whack at this the

        I should also say that I didn't tackle the issue of user breakpoints
hitting into kdb, and thus slowing things down. With my changes, on
i386, a user breakpoint is the same as a kdb breakpoint and so kdb will
first be entered, and now it'll assemble all the CPUs before it decides
that the breakpoint isn't a match. I guess this could be a nuisance for
some users, but you can always turn kdb off (ie. set kdb_on to 0).
Problem solved. If this is really critical to someone, we can deal with
it, but no one has really argued for this.

        -- Ethan

Attachment: kdb_smp.tar.bz2
Description: Binary data

<Prev in Thread] Current Thread [Next in Thread>