George Anzinger wrote:
> I took a look at this and it looks very messy. The whole notion is that
> the stack is available to put the call on and then proceed. The
> question then is what does the stack look like after the call to the
> inferior function which, one way or another get back to the kgdb. I
> think the back trace should show the frames that kgdb put on the stack
> and then trace back to the orgional stack. If gdb is some how not on
> the same stack, we will not see it. In fact the inferior trap/break
> would leave a bit of a mess to clean up. We would have to move the
> stack again, but to a new place, etc.
Yes. putting new parameters etc. on top of the stack inside kgdb
makes back trace show called function, kgdb function calls and then
original kernel function calls. This creates
1. Reentrancy problems.
2. Called function can corrupt kgdb data.
> An alternative solution is to put the call in a seperate memory area and
> put the parameters, etc. on the stack. This would unwind cleanly and
> gdb already drops the inferior call from being useful when it ends other
> than by returning. Some systems do not allow execution from the stack,
> so code already exists in gdb to do this. Problem is a) how to turn it
> on, and b) how to tell gdb where the real sp is so it can lay down the
> call parameters correctly. Of course, even this may be a problem as the
> stub still needs to make calls to get characters from the interface, but
> this could be covered by boosting the stack address given to gdb for the
> inverior function call.
In this case the stack would be broken.
1. It again has reentrancy problems
2. back trace is not clean it's broken.
IMO a better option is to make kgdb intelligent to recognize the fact
that gdb is pushing parameters and calling another function. Save all
this in some other area and put parameters and the call just before
returning from kgdb. This solution does not have reentrancy problems
as artificially constructed call looks similar to a normal call from
called function. No kgdb frames appear in between original function.
kgdb does not need to remember that it has executed a function call.
--
Amit Kale
Veritas Software ( http://www.veritas.com )
