Right, and if I put on the breaks and they don't work because the
factory has not designed the break shoes yet, it is not a bug???
This is a correct description of the problem, but I don't agree that it
is not a bug!
And further, if I can get even a hint (from the maintainers) as to how
to fix the problem, I stand ready to pick at my trusty keys and do it.
Or am I expecting too much?
Corollary to "the squeaky wheel gets the grease": He who complains most
about the squeaking gets to do the greasing.
George
"Amit S. Kale" wrote:
>
> When debugging applications, gdb pushes function parameters on
> *application*'s
> stack. Since kgdb stub shares stack with the kernel code being debugged,
> evaluating a function from gdb currupts the kernel stack.
> This is how stack appears when in debugger (stack grows downward)
>
> address, flags and error code where breakpoint/fault occured
> Saved registers
> Debugger function parameters and local variables
>
> This is not a bug, hence hasn't been addressed yet.
>
> George Anzinger wrote:
> >
> > Using the 386 kgdb code, I wanted to get gdb to evaluate a kernel
> > function. The result wiped out the system (i.e. reboot). I think the
> > problem is that gdb puts the calling code and parameters on the stack,
> > but i386_stub is using the same stack. Gdb only knows the stack address
> > above the call to the stub (i.e. where the trap was taken). This means
> > that the stubs stack is wiped. Has anyone addressed this? What gdb
> > does makes sense if it is using ptrace, but not if it is remote
> > debugging.
> >
> > George
> >
>
> --
> Amit Kale
> Veritas Software ( http://www.veritas.com )
