Re: kgdb support for gdb

["Amit S. Kale" <amitkale at linsyssoft dot com>]

On Monday 04 Oct 2004 10:53 pm, Daniel Jacobowitz wrote:
> On Mon, Oct 04, 2004 at 10:05:24PM +0530, Amit S. Kale wrote:
> > I don't suppress any frames. I insert a fake frame so that the fake frame
> > can do the job of reporting correct registers to the previous frame. IT
> > works more or less like inline functions. At present inline functions
> > don't insert fake frames, but I believe it's being worked on.
>
> FYI, I have inline frames mostly working.  They are sort of "fake"
> frames... but I haven't taken a look at your code, so I'm not sure
> whether what you did is comparable.
>
> > Let me state the problem I am trying to solve. You may be able to provide
> > a better solution to that.
> >
> > schedule() function has a call to macro switch_to. The switch_to macro is
> > an architecture specific macro. It has hand written assembly code that
> > does a part of the context switching job. This code manipulates eip and
> > esp in a non-standard way. Present gdb can't produce backtraces correctly
> > if the frame 0 is inside switch_to. That's obvious since gdb doesn't have
> > dwarf information for those instructions.
> >
> > A few things have been tried to help gdb with this problem. This one is
> > worth mentioning: We report the esp as it would be when switch_to is
> > complete. Since gdb doesn't look into switch_to code, it starts
> > interpretations where switch_to ends. So this works ok for most part. It
> > doesn't solve the problem of all registers, though. The switch_to code
> > has been written intelligently (read over-engineered) to save only those
> > registers which would be expected by gcc to be correct when schedule()
> > function returns. So this task becomes unmanageable and error-prone.
>
> Can you explain why this can't be done with additional DWARF annotation?

Adding dwarf annotation is one problem. It an assembly code so adding dwarf 
annotation isn't easy. George Anzinger has done that in other places (do_IRQ 
in particular), but it's in binary. Not all assemblers used by people support 
the .cfi directives. Highly unmaintainable stuff. It's better not to have 
that than gdb reporting incorrect information.

switch_to is anyway a context switch code. gdb certainly can't be made to 
understand it. It's very similar to signal trampolines where gdb can't debug 
the part that resides outside the trampoline code (kernel code). One side 
effect of inserting this fake frame is that users can't single step in that 
frame. It's good because they accidentally don't try to debug context 
switches through gdb.

-Amit