"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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
