Re: remote kernel gdb stack frames corrupted after breakpoint or step

Kip McAtee writes:
 > Greetings-
 > 
 > I'm building on 5.3-BETA4 (and 6.0 current)
 > with gdb (and kgdb) 6.1.1.
 > 
 > I can get into the remote kernel debugger with
 > sysctl debug.kdb.enter=1
 > 
 > I can set a breakpoint and continue.
 > When it hits the breakpoint I get:
 > 
 > Breakpoint 2, wakeup (ident=0xc0c0f9e8) at ../../../kern/kern_synch.c:253
 > 253             sleepq_broadcast(ident, SLEEPQ_MSLEEP, -1);
 > (kgdb) c
 > Continuing.
 > 
 > Program received signal SIGSEGV, Segmentation fault.
 > 
 > Looking at the backtrace implies that the stack frames
 > are not displayed correctly. I'm setting:
 > 

FWIW, I see the same thing when continuing from breakpoints in
RELENG_5 via ddb.  I've appended a log from my serial console.

Interestingly, dropping into the debugger via break on console works
like a charm, its only inserted breakpoints which don't work.
I think this started happening after the ddb->kdb conversion.

Drew

[send halt on serial console]
db> break sched_switch
db> c
[thread 100004]
Stopped at      sched_switch+0x1:       movl    %esp,%ebp
db> tr
sched_switch(1,0,0,0,0) at sched_switch+0x1
idle_proc(0,e3f78d48,10e90,10e98,10ea0) at idle_proc+0x143
fork_exit(c04fa329,0,e3f78d48) at fork_exit+0x80
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe3f78d7c, ebp = 0 ---
db> c


kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc0527256
stack pointer           = 0x10:0xe3f78c8c
frame pointer           = 0x10:0xe3f78c9c
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = resume, IOPL = 0
current process         = 12 (idle: cpu0)
[thread 100004]
Stopped at      sched_switch+0xe:       movl    0(%ebx),%edx
db> tr   
sched_switch(0,10,44096318,47c326eb,ffc00014) at sched_switch+0xe
end(74c085d0,b816,a3640000,c,89d0558b) at 0xc1562640
db> call cpu_reset
cpu_reset called on cpu#0