KGDB 2.0.3 with fixes and development in ethernet interface

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

++int kgdbeth_thread(void *data)
++{

++      struct net_device *ndev = (struct net_device *)data;
++      daemonize("kgdbeth");
++      while (!ndev->ip_ptr) {
++              schedule();
++      }
++      debugger_entry();
++      return 0;

Don't you need some locking around ndev->ip_ptr? [Okay, it probably only matters on SMP, so it is not causing your problems..]

Quoted 10 lines · Pavel Machek

++int kgdbeth_thread(void *data)
++{

++      struct net_device *ndev = (struct net_device *)data;
++      daemonize("kgdbeth");
++      while (!ndev->ip_ptr) {
++              schedule();
++      }
++      debugger_entry();
++      return 0;

Quoted 2 lines

Don't you need some locking around ndev->ip_ptr? [Okay, it probably only matters on SMP, so it is not causing your problems..]

Not to mention it should use a proper wait_event instead of this really stupid loop.

Hi!

Quoted 6 lines

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

++int kgdbeth_thread(void *data)
++{

++      struct net_device *ndev = (struct net_device *)data;
++      daemonize("kgdbeth");
++      while (!ndev->ip_ptr) {
++              schedule();
++      }
++      debugger_entry();
++      return 0;

Don't you need some locking around ndev->ip_ptr? [Okay, it probably only matters on SMP, so it is not causing your problems..]

Quoted 17 lines

Quoted 6 lines

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

++int kgdbeth_thread(void *data)
++{

++      struct net_device *ndev = (struct net_device *)data;
++      daemonize("kgdbeth");
++      while (!ndev->ip_ptr) {
++              schedule();
++      }
++      debugger_entry();
++      return 0;

Quoted 2 lines

Don't you need some locking around ndev->ip_ptr? [Okay, it probably only matters on SMP, so it is not causing your problems..]

Yes. Some locking will be needed. I haven't yet figured out the exact sequence of function calls during configuration of an interface from userland.

Is there a hold-count kind of a thing on network interface components (like inodes, dentries)?

I am still using userland to bring an interface up. I guess it's best done inside the kernel instead of using notifications and spawning a thread. Then the interface would be usable much earlier.

Hi,

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

On Fri, 16 Jan 2004 17:59:59 +0530

Quoted 2 lines · Amit S. Kale

Hi,

Quoted 5 lines

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

Did you add the fix for netpoll Jim posted?

Quoted 7 lines

Quoted 5 lines

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

Did you add the fix for netpoll Jim posted?

I am not using netpoll (yet). My patch doesn't require any driver modifications, that the mm ethernet patch required.

Hi!

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

Quoted 4 lines

Quoted 1 line

Did you add the fix for netpoll Jim posted?

I am not using netpoll (yet). My patch doesn't require any driver modifications, that the mm ethernet patch required.

Does that mean that you are going to use netpoll, eventually?

Quoted 7 lines

Quoted 5 lines

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

Did you add the fix for netpoll Jim posted?

I am not using netpoll (yet). My patch doesn't require any driver modifications, that the mm ethernet patch required.

Hi!

Quoted 11 lines

Quoted 8 lines

Quoted 6 lines

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

Did you add the fix for netpoll Jim posted?

I am not using netpoll (yet). My patch doesn't require any driver modifications, that the mm ethernet patch required.

int kgdbeth_event(struct notifier_block * self, unsigned long val, void * data)

{
        if (strcmp(((struct net_device *)data)->name, "eth0")) {
                goto out;
        }
        if (val!= NETDEV_UP)
                goto out;

Do I read it correctly as "eth0 is not to be used for debugging"? So if I only have eth0 here, I have to comment it out, right?

Quoted 9 lines

int kgdbeth_event(struct notifier_block * self, unsigned long val, void * data)

{
        if (strcmp(((struct net_device *)data)->name, "eth0")) {
                goto out;
        }
        if (val!= NETDEV_UP)
                goto out;

Quoted 2 lines

Do I read it correctly as "eth0 is not to be used for debugging"? So if I only have eth0 here, I have to comment it out, right?

No. It uses only "eth0" for debugging. If you have only eth0, it'll use that for debugging.

Hi!

Quoted 9 lines

Quoted 9 lines

int kgdbeth_event(struct notifier_block * self, unsigned long val, void * data)

{
        if (strcmp(((struct net_device *)data)->name, "eth0")) {
                goto out;
        }
        if (val!= NETDEV_UP)
                goto out;

Quoted 5 lines

Quoted 2 lines

Do I read it correctly as "eth0 is not to be used for debugging"? So if I only have eth0 here, I have to comment it out, right?

No. It uses only "eth0" for debugging. If you have only eth0, it'll use that for debugging.

Perhaps this is good idea? It should be documented somewhere... Please apply,
Pavel

Documentation/kgdb/ethernet.txt new file +16 -0

+0100 @@ -0,0 +1,15 @@
+Some notes about kgdb over ethernet
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ 2004 Pavel Machek <[email protected]>
+
+Pass this on kernel commandline:
+
+	kgdbeth=interfacenum,localmac,listenport,remoteip,remotemac gdb
+
+Boot local machine. At the point where you enable eth0, machine will
+hang, waiting for remote gdb to connect. At that point, type this on
+remote machine:
+
+   $ gdb ./vmlinux
+   (gdb) target remote udp:HOSTNAME:6443

Hi All,

I extracted this part of Pavel the patch he had submitted for 2.0.3 and appended it to README file. Since Pavel has't noticed it, I am assuming that most people won't notice it either.

Do people think pushing documentation into Documentation/kgdb directory is a better idea?

Another note about kgdb documentation - There is a lot of documentation at kgdb.sourceforge.net. It's more of howto type rather than manpages. Will it be too much as a documentation in kernel sources.

Any ideas on which things to put into Documentation/kgdb and which to have on a website.

Quoted 8 lines · Andi Kleen

On Fri, 16 Jan 2004 17:59:59 +0530

Quoted 5 lines · Amit S. Kale

Hi,

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Quoted 4 lines

Quoted 2 lines

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

Did you add the fix for netpoll Jim posted?

I am not using netpoll (yet). My patch doesn't require any driver modifications, that the mm ethernet patch required.

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

It panics and enter kgdb_handle_exception recursively and silently. To see the panic on screen make kgdb_handle_exception return immediately if kgdb_connected is non-zero.

Panic trace is pasted below. It panics in skb_release_data. Looks like skb handling will have to changed to be have kgdb specific buffers.

Hi,

KGDB 2.0.3 is available at http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

It panics and enter kgdb_handle_exception recursively and silently. To see the panic on screen make kgdb_handle_exception return immediately if kgdb_connected is non-zero.

Panic trace is pasted below. It panics in skb_release_data. Looks like skb handling will have to changed to be have kgdb specific buffers.

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

It panics and enter kgdb_handle_exception recursively and silently. To see the panic on screen make kgdb_handle_exception return immediately if kgdb_connected is non-zero.

Panic trace is pasted below. It panics in skb_release_data. Looks like skb handling will have to changed to be have kgdb specific buffers.

Hi!

Quoted 4 lines

KGDB 2.0.3 is available at http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

Quoted 3 lines

It panics and enter kgdb_handle_exception recursively and silently. To see the panic on screen make kgdb_handle_exception return immediately if kgdb_connected is non-zero.

Panic trace is pasted below. It panics in skb_release_data. Looks like skb handling will have to changed to be have kgdb specific buffers.

This seems to be needed (if I unselect CONFIG_KGDB_THREAD, I get compile error on x86-64).

Quoted 12 lines · Pavel Machek

Hi!

Quoted 10 lines

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

It panics and enter kgdb_handle_exception recursively and silently. To see the panic on screen make kgdb_handle_exception return immediately if kgdb_connected is non-zero.

Quoted 5 lines

Quoted 2 lines

Panic trace is pasted below. It panics in skb_release_data. Looks like skb handling will have to changed to be have kgdb specific buffers.

This seems to be needed (if I unselect CONFIG_KGDB_THREAD, I get compile error on x86-64).

Amit, could you explain why this is an option? It seems very useful and not really too much code...

Quoted 21 lines · George Anzinger

Quoted 18 lines · Pavel Machek

Hi!

Quoted 6 lines

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

Quoted 6 lines

It panics and enter kgdb_handle_exception recursively and silently. To see the panic on screen make kgdb_handle_exception return immediately if kgdb_connected is non-zero.

Panic trace is pasted below. It panics in skb_release_data. Looks like skb handling will have to changed to be have kgdb specific buffers.

This seems to be needed (if I unselect CONFIG_KGDB_THREAD, I get compile error on x86-64).

Quoted 2 lines

Amit, could you explain why this is an option? It seems very useful and not really too much code...

It saves all registers before switch_to. It does that two times at present. Once (implicit) register save by gcc and an explicit register save in arch/<proc>/kernel/entry.S Second register save in kern_schedule generates a pt_regs structure which gdb can get all registers at once from. If it's omited, gdb has to figure out where gcc has saved registers from the non-standards code in switch_to, which it can't do correctly all the time.

We can have a check for (a new variable) debugger_enabled before calling kern_schedule. That'll be add negligible overhead and will allow extra thread info to be saved only when a debugger is enabled. There will not be any need for CONFIG_KGDB_THREAD also.

Quoted 32 lines · Amit S. Kale

Quoted 14 lines · George Anzinger

Quoted 13 lines · Pavel Machek

Hi!

Quoted 11 lines

KGDB 2.0.3 is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.3.tar.bz2

Ethernet interface still doesn't work. It responds to gdb for a couple of packets and then panics. gdb log for ethernet interface is pasted below.

It panics and enter kgdb_handle_exception recursively and silently. To see the panic on screen make kgdb_handle_exception return immediately if kgdb_connected is non-zero.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

Panic trace is pasted below. It panics in skb_release_data. Looks like skb handling will have to changed to be have kgdb specific buffers.

This seems to be needed (if I unselect CONFIG_KGDB_THREAD, I get compile error on x86-64).

Amit, could you explain why this is an option? It seems very useful and not really too much code...

It saves all registers before switch_to. It does that two times at present. Once (implicit) register save by gcc and an explicit register save in arch/<proc>/kernel/entry.S Second register save in kern_schedule generates a pt_regs structure which gdb can get all registers at once from. If it's omited, gdb has to figure out where gcc has saved registers from the non-standards code in switch_to, which it can't do correctly all the time.

Quoted 4 lines

We can have a check for (a new variable) debugger_enabled before calling kern_schedule. That'll be add negligible overhead and will allow extra thread info to be saved only when a debugger is enabled. There will not be any need for CONFIG_KGDB_THREAD also.

I don't seem to have such a problem with the mm kgdb. No kern_schedule there...

Now back to gdb problem of not being able to locate registers. schedule results in code of this form:

schedule:
framesetup
registers save
...
...
save registers
change esp
call switchto
restore registers
...
...

GDB can't analyze code other than frame setup and registers save. It may not show values of variables that are present in registers correctly. This used to be a problem some time ago (gdb 5.X). Perhaps gdb 6.x does a better job. hmm...
May be its time I should look at gdb's x86 register info code again.

Quoted 15 lines · Amit S. Kale

Now back to gdb problem of not being able to locate registers. schedule results in code of this form:

schedule:
framesetup
registers save
...
...
save registers
change esp
call switchto
restore registers
...
...

Quoted 3 lines

GDB can't analyze code other than frame setup and registers save. It may not show values of variables that are present in registers correctly. This used to be a problem some time ago (gdb 5.X). Perhaps gdb 6.x does a better job. hmm...
May be its time I should look at gdb's x86 register info code again.

You should try GDB 6.0, which will use the dwarf2 unwind information to accurately locate registers in any GCC-compiled code with -gdwarf-2 (-g on Linux targets).

As George is now painfully familiar with :)

Quoted 15 lines · Amit S. Kale

Now back to gdb problem of not being able to locate registers. schedule results in code of this form:

schedule:
framesetup
registers save
...
...
save registers
change esp
call switchto
restore registers
...
...

Quoted 5 lines

GDB can't analyze code other than frame setup and registers save. It may not show values of variables that are present in registers correctly. This used to be a problem some time ago (gdb 5.X). Perhaps gdb 6.x does a better job. hmm...
May be its time I should look at gdb's x86 register info code again.

You should try GDB 6.0, which will use the dwarf2 unwind information to accurately locate registers in any GCC-compiled code with -gdwarf-2 (-g on Linux targets).

CONFIG_KGDB_THREAD save code will still be required on other processors. Powerpc for example has _switch assembly function that does a lot of things, including saving registers on stack.

Quoted 4 lines · George Anzinger

Quoted 2 lines · Amit S. Kale

On Saturday 17 Jan 2004 6:53 am, George Anzinger wrote:

Quoted 19 lines

Quoted 18 lines

Quoted 5 lines

Quoted 2 lines

This seems to be needed (if I unselect CONFIG_KGDB_THREAD, I get compile error on x86-64).

Amit, could you explain why this is an option? It seems very useful and not really too much code...

It saves all registers before switch_to. It does that two times at present. Once (implicit) register save by gcc and an explicit register save in arch/<proc>/kernel/entry.S Second register save in kern_schedule generates a pt_regs structure which gdb can get all registers at once from. If it's omited, gdb has to figure out where gcc has saved registers from the non-standards code in switch_to, which it can't do correctly all the time.

We can have a check for (a new variable) debugger_enabled before calling kern_schedule. That'll be add negligible overhead and will allow extra thread info to be saved only when a debugger is enabled. There will not be any need for CONFIG_KGDB_THREAD also.

Quoted 2 lines

I don't seem to have such a problem with the mm kgdb. No kern_schedule there...

Have you confirmed that you see correct values for all the registers? I had found some problems with gdb not being able to locate all the registers correctly. Explanation on the problem below:

Besides getting gdb's fault there is one more benefit of kern_schedule. All threads are shown by gdb as sleeping _at_ the place where schedule call is present: So instead of gdb showing all threads sleeping in __switch_to, it shows several functions. That's better than having to look at back trace of each thread to figure out what it is.

This functionality is complemented by printing of thread names in 2.0.X kgdb info threads listing.

Now back to gdb problem of not being able to locate registers. schedule results in code of this form:

schedule:
framesetup
registers save
...
...
save registers
change esp
call switchto
restore registers
...

...

GDB can't analyze code other than frame setup and registers save. It may not show values of variables that are present in registers correctly. This used to be a problem some time ago (gdb 5.X). Perhaps gdb 6.x does a better job. hmm...
May be its time I should look at gdb's x86 register info code again.

Quoted 29 lines · Amit S. Kale

Quoted 16 lines · George Anzinger

Quoted 15 lines · Amit S. Kale

Quoted 5 lines · George Anzinger

Quoted 2 lines

This seems to be needed (if I unselect CONFIG_KGDB_THREAD, I get compile error on x86-64).

Amit, could you explain why this is an option? It seems very useful and not really too much code...

It saves all registers before switch_to. It does that two times at present. Once (implicit) register save by gcc and an explicit register save in arch/<proc>/kernel/entry.S Second register save in kern_schedule generates a pt_regs structure which gdb can get all registers at once from. If it's omited, gdb has to figure out where gcc has saved registers from the non-standards code in switch_to, which it can't do correctly all the time.

Quoted 7 lines

Quoted 4 lines

We can have a check for (a new variable) debugger_enabled before calling kern_schedule. That'll be add negligible overhead and will allow extra thread info to be saved only when a debugger is enabled. There will not be any need for CONFIG_KGDB_THREAD also.

I don't seem to have such a problem with the mm kgdb. No kern_schedule there...

Have you confirmed that you see correct values for all the registers? I had found some problems with gdb not being able to locate all the registers correctly. Explanation on the problem below:

Quoted 5 lines

Besides getting gdb's fault there is one more benefit of kern_schedule. All threads are shown by gdb as sleeping _at_ the place where schedule call is present: So instead of gdb showing all threads sleeping in __switch_to, it shows several functions. That's better than having to look at back trace of each thread to figure out what it is.

The mm version of kgdb does this, but by lying to gdb during the info thread command. IMNSHO, the real way to do this is to process the info thread output with an awk script, but I haven't done that just yet. The problem with lying to gdb is that it sometimes remembers...

Quoted 2 lines

This functionality is complemented by printing of thread names in 2.0.X kgdb info threads listing.

as in the mm version.

Quoted 13 lines

Now back to gdb problem of not being able to locate registers. schedule results in code of this form:

schedule:
framesetup
registers save
...
...
save registers
change esp
call switchto
restore registers
...

I have not analyzed this as yet. However, it does seem to me to be the same problem as trying to bt through an interrupt frame. The correct way to do this is to build the dwarf frame descriptors. I have done this for the interrupt frame and intend to send said patch out in a day or so.

Could be I should look at the above and do the right thing for it also.

Quoted 7 lines

...

GDB can't analyze code other than frame setup and registers save. It may not show values of variables that are present in registers correctly. This used to be a problem some time ago (gdb 5.X). Perhaps gdb 6.x does a better job. hmm...
May be its time I should look at gdb's x86 register info code again.

The latter gdbs (not sure when) are using dwarf frame code. The asm code needs to be anotated to make this work. There is a problem I reported a couple of days ago with the dwarf expression code. I think it is fixed, but that would still be the cvs version of gdb.

I think I would rather NOT modify kernel code and put up with the register loss in some cases. I am MUCH more concerned with unexpected behavior due to the code changes. Heisenberg is NOT our friend.

Quoted 15 lines · George Anzinger

Quoted 13 lines · Amit S. Kale

Now back to gdb problem of not being able to locate registers. schedule results in code of this form:

schedule:
framesetup
registers save
...
...
save registers
change esp
call switchto
restore registers
...

Quoted 4 lines

I have not analyzed this as yet. However, it does seem to me to be the same problem as trying to bt through an interrupt frame. The correct way to do this is to build the dwarf frame descriptors. I have done this for the interrupt frame and intend to send said patch out in a day or so.

Great! I had to do it this ackward way:

i386 ->

I guess your patch will fix this problem for i386 only. Any ideas on doing it for powerpc too?

Quoted 18 lines · Amit S. Kale

Quoted 16 lines · George Anzinger

Quoted 13 lines · Amit S. Kale

Now back to gdb problem of not being able to locate registers. schedule results in code of this form:

schedule:
framesetup
registers save
...
...
save registers
change esp
call switchto
restore registers
...

Quoted 8 lines

Quoted 4 lines

I have not analyzed this as yet. However, it does seem to me to be the same problem as trying to bt through an interrupt frame. The correct way to do this is to build the dwarf frame descriptors. I have done this for the interrupt frame and intend to send said patch out in a day or so.

Great! I had to do it this ackward way:

i386 ->

[snip]

Quoted 1 line

I guess your patch will fix this problem for i386 only. Any ideas on doing it for powerpc too?

Maybe I'm missing something, but aside from having to re-write the solution in PPC asm, if it's in i386 asm, why wouldn't this work for PPC as well?

Daniel has suggested that we could just use the new bin tools where in the gas program will build the call frames. I am not sure it can handle expressions, however. And they are needed if you want to tie off the frame if the next step is user land.

By the way, I don't try to build a blow by blow of the frame. Rather I assume it is only of interest at those points where calls are made out of the interrupt /trap code. (Or, in some cases, jumps are made back into it.)

Quoted 60 lines · George Anzinger

Quoted 29 lines · Amit S. Kale

Quoted 16 lines · George Anzinger

Quoted 15 lines · Amit S. Kale

Quoted 5 lines · George Anzinger

Quoted 2 lines

This seems to be needed (if I unselect CONFIG_KGDB_THREAD, I get compile error on x86-64).

Amit, could you explain why this is an option? It seems very useful and not really too much code...

It saves all registers before switch_to. It does that two times at present. Once (implicit) register save by gcc and an explicit register save in arch/<proc>/kernel/entry.S Second register save in kern_schedule generates a pt_regs structure which gdb can get all registers at once from. If it's omited, gdb has to figure out where gcc has saved registers from the non-standards code in switch_to, which it can't do correctly all the time.

Quoted 7 lines

Quoted 4 lines

We can have a check for (a new variable) debugger_enabled before calling kern_schedule. That'll be add negligible overhead and will allow extra thread info to be saved only when a debugger is enabled. There will not be any need for CONFIG_KGDB_THREAD also.

I don't seem to have such a problem with the mm kgdb. No kern_schedule there...

Have you confirmed that you see correct values for all the registers? I had found some problems with gdb not being able to locate all the registers correctly. Explanation on the problem below:

Quoted 5 lines

Besides getting gdb's fault there is one more benefit of kern_schedule. All threads are shown by gdb as sleeping _at_ the place where schedule call is present: So instead of gdb showing all threads sleeping in __switch_to, it shows several functions. That's better than having to look at back trace of each thread to figure out what it is.

The mm version of kgdb does this, but by lying to gdb during the info thread command. IMNSHO, the real way to do this is to process the info thread output with an awk script, but I haven't done that just yet. The problem with lying to gdb is that it sometimes remembers...

Quoted 2 lines

This functionality is complemented by printing of thread names in 2.0.X kgdb info threads listing.

as in the mm version.

Quoted 13 lines

Now back to gdb problem of not being able to locate registers. schedule results in code of this form:

schedule:
framesetup
registers save
...
...
save registers
change esp
call switchto
restore registers
...

Quoted 4 lines

I have not analyzed this as yet. However, it does seem to me to be the same problem as trying to bt through an interrupt frame. The correct way to do this is to build the dwarf frame descriptors. I have done this for the interrupt frame and intend to send said patch out in a day or so.

Great! I had to do it this ackward way: