> > > > I guess Christoph, Roland and Frank would be able to explain in a better > > fashion the rational and advantages of this stub over convential gdb. > > Hmm,. wouldn't it make much more sense to extend the current kgdb stub > to include userspace debugging, providing an all-in-one solution?
I see two limitations but I guess there could be ways to get over it. 1. gdb requiring file that needs to be debugged. I always thought it can either be a user program or a vmlinux file. gdb makes most of the information(i.e registers) from the remote protocol to display the backtrace, variable values and the like by reading this file. 2. Also I am not sure if gdb has a way to tell the remote to switch the context and provide information(registers) pertaining to the user mode/ kernel mode. There could be other limitations too that I may not be aware. > > I think it would be much more powerful to be able to observe the full > software stack and not be limited by this user<->kernel barrier. > > (Provided the user has sufficient privileges of course). In this implementation, the current user can debug his/her own processes. May be if we can debug both the context from same gdb then we might have to place restrictions.. -- Thanks and Regards Srikar >
