On 10/25, Ananth N Mavinakayanahalli wrote: > > 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? Well, personally I think this is acceptable. Once again, uprobes were designed to be "system wide", and each uprobe connects to the file. This int3 reflects this fact. In any case, I do not see how we can hide these int3's. Perhaps we can fool ptrace/core, but I am not sure this would be really good, this can add more confusion. And the application itself can read its .text and see int3, what can we do? Oleg. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>