I forgot to mention that there's a rather large caveat here. If a user
has the dtrace_user or dtrace_kernel privilege, but _not_ the dtrace_proc
privilege he won't be able to use pid provider probes.
I think the two options are to either support both breakpoints in libdtrace
as a fallback position, to work on getting dtrace_proc in the list of default
(basic) privileges, or give up on the bug for now.
Adam
On Sun, Jan 06, 2008 at 08:37:32PM -0500, Chad Mynhier wrote:
> I've been looking at this bug. What I think needs to be done is the
> following:
>
> - In dt_proc_control(), create a separate dtrace handle with the
> destructive option set.
> - In dt_proc_bp_create() (or the equivalent-but-renamed function), do
> something similar to the following instead of creating a breakpoint
> (where dtp is this new handle):
>
> sprintf(dprog, "pid%d::-:%x {stop();}", (int)dpr->dpr_pid,
> dbp->dbp_addr);
>
> if ((pgp = dtrace_program_strcompile(dtp, dprog,
> DTRACE_PROBESPEC_NAME, DTRACE_C_NOLIBS, 0, NULL))
> == NULL) {
> dt_dprintf("pid %d: failed to compile pid breakpoint "
> "at 0x%x\n", (int)dpr->dpr_pid, dbp->dbp_addr);
> } else if (dtrace_program_exec(dtp, pgp, NULL)
> == -1) {
> dt_dprintf("pid %d: failed to create pid breakpoint "
> "at 0x%x\n", (int)dpr->dpr_pid, dbp->dbp_addr);
> } else {
> dbp->dbp_active = B_TRUE;
> }
>
> - In the dt_proc_bpmatch() equivalent, match exactly as we currently
> do, by comparing the current PC with dbp->dbp_addr (but not executing
> the breakpoint-replaced instruction).
> - In dt_proc_control(), call the dt_proc_bpmatch() equivalent similar
> to the following ("pbp" for "pid breakpoint", for want of a better
> name):
>
> case PS_STOP:
> psp = &Pstatus(P)->pr_lwp;
> if (psp->pr_why == PR_REQUESTED) {
> if (dt_proc_pbpmatch(pbp_dtp, dpr) == -1) {
> dt_proc_waitrun(dpr);
> (void) pthread_mutex_unlock(
> &dpr->dpr_lock);
> continue;
> }
> }
>
> (There's still the question of what to do with dt_proc_bpdestroy(),
> dt_proc_bpenable() and dt_proc_disable().)
>
> I've tried the above, and I see the probes being created, but these
> probes never fire. What's more, the probes in the D script I'm
> running are never created, although I believe that's just because the
> RD_DLACTIVITY probe is never firing, thus
> dt_pid_create_probes_module() is never called.
>
> Any ideas? I've put a copy of dt_proc.[ch] and DTRACE_DEBUG output at
> http://cr.opensolaris.org/~cmynhier/6593259/ if you want to look at
> it.
>
> Thanks,
> Chad
> _______________________________________________
> dtrace-discuss mailing list
> [email protected]
--
Adam Leventhal, FishWorks http://blogs.sun.com/ahl
_______________________________________________
dtrace-discuss mailing list
[email protected]
