Understanding gdb way down inside.

[george anzinger]

I am working on a kgdb patch for linux x86 kernels.  It
correctly treats kernel tasks as threads and allows one to
look at each task in the kernel.

The problem I am having is understanding how gdb does the
"up" command.  I assumed that it would use the EBP register
to find the previous EBP (*EBP) and PC (*(EBP+4)) as well as
the previous ESP (EBP+8).  It seems to do this "some" of the
time.  In the failing case it seems to be finding PC by
using *ESP, which would seem to imply that gdb thinks there
is no stack frame AND that ESP is as it was when the
function was entered.  I see several accesses to *PC and
wonder if someone could tell me what is going on here, or at
least what bit of code in gdb to study to figure it out.

The net result of this problem is that an additional bogus
frame is included in the back trace.

I would also like to know if it is possible to get gdb to
correctly "UP" an interrupt frame.  I am hopping to do what
is needed in the kernel resident stub, if only I know what
that is.
-- 
George Anzinger   address@hidden
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml