* Roland McGrath rol...@redhat.com [2010-07-12 22:59:05]:
When I had posted a prototype of a gdbstub which Frank and I had
worked on. http://lkml.org/lkml/2009/11/30/173, Peter and Ingo
showed a preference for a combined gdbstub in kernel, i.e kgdb and the
newer stub should use only one
Given these requirements, and given that the 'new' uprobes is close to
-tip, would it be more useful to pursue an alternate syscall approach
rather than gdbstub?
Feel free to pursue whatever you like. For our own time allocation, we
see an effort along those lines now as a distraction from
What is the reasoning for selecting /proc/ugdb instead of something like
/proc/pid/ugdb?
The protocol, and gdb, support dealing with many processes over one control
channel. For normal the debugger model to work where it can attach to a
process on demand, with your model it would have to open
On 07/13, Ananth N Mavinakayanahalli wrote:
Given these requirements, and given that the 'new' uprobes is close to
-tip, would it be more useful to pursue an alternate syscall approach
rather than gdbstub?
Roland has already answered, and I agree.
The problem is that we do not have the new
On 07/12, Roland McGrath wrote:
Please see the attachment. Don't take this code seriously, this is
the early prototype and everything should be rewritten. It barely
uses utrace, only to stop the target.
You've got to start somewhere!
Yes ;)
And now I am going to rewrite this code
Ananth == Ananth N Mavinakayanahalli ana...@in.ibm.com writes:
Ananth OTOH, the Tom Tromey alluded on lkml that if kernel provides
Ananth infrastructure that allows for breakpoint assistance and 'displaced'
Ananth stepping, with a suitable user interface, preferably a ptrace variant
Ananth that
