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