gdbstub initial code

[Ananth N Mavinakayanahalli]

On Mon, Jul 12, 2010 at 08:37:29PM +0200, Oleg Nesterov wrote:
> Hello.
> 
> 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.
> 
> 	(gdb) file /path/to/binary
> 	(gdb) target extended-remote /proc/ugdb
> 	(gdb) attach PID
> 	(gdb) disassemble _start
> 	(gdb) bt
> 	(gdb) info registers
> 	(gdb) info threads
> 	(gdb) detach
> 
> This seems to work, but I had to export access_process_vm().
> 
> Currently it only attaches to the single thread. vCont or ^C doesn't
> work.
> 
> I still can't understand what utrace_xxx_pid() buys us, and I still
> think that utrace_prepare_examine() can't protect the task even for
> regset calls.

IMHO, if this is the start of another stab at getting utrace in the
upstream kernel, you may want to consider Linus' problem statement
for utrace -- infrastructure that will allow strace and gdb on the
same thread at the same time.

OTOH, the Tom Tromey alluded on lkml that if kernel provides
infrastructure that allows for breakpoint assistance and 'displaced'
stepping, with a suitable user interface, preferably a ptrace variant
that is fd based, they'll migrate gdb to using the interface. (The bp
assistance and displaced stepping can be provided with extensions to
the current uprobes set under review).

In any case, its good to see a restart of this effort. Though there
has been support for gdbstub in the past, an overwhelming majority
of people would like to see a 'user interface', be it ptrace2 or
PTRACE_ATTACH2 or whatever it needs to be called.

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?

Ananth