"Amit S. Kale" wrote:
>
> 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.
Well I guess I am up for the chalange. Is there a clue when this is
happening other than a write to the stack area? I assume gdb expects,
on return, to be able to just continue to resume the program. How is
the completion of the inferior function recognized? Could be a
breakpoint or some return to the gdb. Hm, lets see, in a ptrace
environment the only available option is a breakpoint. Right?
George
