🚀 go-pugleaf

george anzinger <george@mvista.com> writes:
> 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.

This is very involved.  Stack unwinding is one of the more complex
parts of GDB.  Although it's generally easy to find the saved PC, GDB
also wants to find all the saved registers in the frame, so it can
print register-allocated variables in frames other than the youngest.

You'll want to look at `struct frame_info', the function
`get_prev_frame', and the frame-related stuff in i386-tdep.c.

There is stuff for handling signal handler invocation frames, but I
doubt there is anything for handling raw IA-32 interrupt frames.
Doesn't the IA-32 switch stacks anyway when it services an interrupt?
(I am very ignorant of how the kernel works.)

Jim Blandy wrote:
> 
> george anzinger <george@mvista.com> writes:
> > 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.
> 
> This is very involved.  Stack unwinding is one of the more complex
> parts of GDB.  Although it's generally easy to find the saved PC, GDB
> also wants to find all the saved registers in the frame, so it can
> print register-allocated variables in frames other than the youngest.
> 
> You'll want to look at `struct frame_info', the function
> `get_prev_frame', and the frame-related stuff in i386-tdep.c.

Thanks.  It seems to not grok some of the preamble code gcc is putting out.  Could be the "assembly" option is messing things up.
> 
> There is stuff for handling signal handler invocation frames, but I
> doubt there is anything for handling raw IA-32 interrupt frames.
> Doesn't the IA-32 switch stacks anyway when it services an interrupt?
> (I am very ignorant of how the kernel works.)

Some times.  If the interrut is from user land it switches stacks.  Kernel stacks are used for interrupts in the kernel, which, of course, is what I am interested in.
-- 
George Anzinger   george@mvista.com
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