Andrew Cagney wrote:
>
> 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.
>
> The mechanism that GDB uses to perform inferior function calls works
> just fine when talking to standard remote stub.
>
> Could I encourage you to investigate ways of modifing your kgdb stub so
> that it can better handle GDBs behavour. One possible way is to have a
> separate stack dedicated to the stub and migrate across to that after
> the interrupt has been taken.
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.
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.
Another question is, HASN'T THIS WHEEL ALREADY BEEN INVENTED?
George
