Re: [Bug uprobes/9826] gdb/uprobes deathmatch goes to OT

[Mark Wielaard <mjw at redhat dot com>]

Hi Jim,

On Fri, 2009-02-06 at 15:20 -0800, Jim Keniston wrote:
> On Fri, 2009-02-06 at 22:14 +0000, mhiramat at redhat dot com wrote:
> > ------- Additional Comments From mhiramat at redhat dot com  2009-02-06 22:14 -------
> > Can gdb use uprobe for probing target process?
> > I think if the kernel supports a 'standard' method of setup break point, gdb
> > doesn't need to tweak target code manually.
> > 
> [I'm replying outside bugzilla, since topic is much broader than the
> subject of #9826.]

Thanks for taking this to the list.
And sorry for confusing matters on bug #7082.
To quote from that one to get some context:

> In bugzilla #7082, Comment #27, Mark Wielaard said:
> > > In any case, do you see the same sort of failure if you turn the return probe
> > > into an entry probe (a al #7092)?
> > 
> > That also fails, although slightly differently:
> > $ stap -ve 'probe process("bash").function("main") {}' -w
> > 
> > And in GDB:
> > (gdb) run
> > Starting program: /bin/bash 
> > 
> > Program terminated with signal SIGILL, Illegal instruction.
> > The program no longer exists.
> > You can't do that without a process to debug.
> > 
> > In both cases 2.6.27.12-170.2.5.fc10.x86_64 under xen.
> 
> The basic problem here is that gdb and stap/uprobes are both trying
> to set breakpoints at the same spot -- e.g., at the entry to main().

Aha, OK. So it wasn't my intention to highlight that fact.
And I actually didn't know that would happen.

I was just running the program being traced under gdb to show how/why it
crashed (with a SIGILL, SIGSEGV or SIGTRAP) when tracing with uprobes.
Now I see gdb might be lying to me. doh.

What method do you use to inspect a user space probe going wrong if you
cannot rely on gdb?

Thanks,

Mark