Re: [PATCH 13/X] uprobes: introduce UTASK_SSTEP_TRAPPED logic

From: Ananth N Mavinakayanahalli
Date: Tue Oct 25 2011 - 02:02:00 EST

On Mon, Oct 24, 2011 at 06:13:06PM +0200, Oleg Nesterov wrote:
> On 10/24, Ananth N Mavinakayanahalli wrote:
> >
> > Thinking further on this, in the normal 'running gdb on a core' case, we
> > won't have this problem, as the binary that we point gdb to, will be a
> > pristine one, without the uprobe int3s, right?
> Not sure I understand.
> I meant, if we have a binary with uprobes (iow, register_uprobe() installed
> uprobes into that file), then gdb will see int3's with or without the core.
> Or you can add uprobe into glibc, say you can probe getpid(). Now (again,
> with or without the core) disassemble shows that getpid() starts with int3.
> But I guess you meant something else...

No, you are right... my inference was wrong. On a core with a uprobe
with an explicit raise(SIGABRT) does show the breakpoint.

(gdb) disassemble start_thread2
Dump of assembler code for function start_thread2:
0x0000000000400831 <+0>: int3
0x0000000000400832 <+1>: mov %rsp,%rbp
0x0000000000400835 <+4>: sub $0x10,%rsp
0x0000000000400839 <+8>: mov %rdi,-0x8(%rbp)
0x000000000040083d <+12>: callq 0x400650 <getpid@plt>

Now, I guess we need to agree on what is the acceptable behavior in the
uprobes case. What's your suggestion?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at