Re: Kernel Debugging
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. enjoy, Andrew
Re: Kernel Debugging
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
Re: Kernel Debugging
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 )
