On Fri, Mar 19, 2010 at 12:31:04PM +0000, Mark R. Bowyer wrote: > Now, first glance, I asked why they were monitoring a 64-bit application > with 32-bit code. But they do, and everywhere else they manage it.
You can't do that. What they are trying to do is observe a 32-bit user-land application that uses 64-bit types. DTrace's PID provider can't possibly know that some argument is 64 bits because it doesn't consume user-land CTF data. (Many of us have asked for DTrace to be able to use user-land CTF data and make plenty of syntactic sugar available for chasing user-land pointers, accessing struct fields, etcetera, with automatically generated D code that does whatever copyins are required, but the answer is always that that would be a huge project.) > [...] > is somewhat confusing, as now that 64-bit value is taking up *2* args, > not the one you'd expect. Yes. I believe you just have to be aware of this and deal with it. > > Dtrace probe: > > adv$1:::myprobe > > { > > /* translation section */ > > this->param1 = (curpsinfo->pr_dmodel == PR_MODEL_LP64) ? > > arg0 : (`utsname.machine == "i86pc") ? ((arg1 << 32) | > > arg0) : ((arg0 << 32) | arg1); I'd do the curpsinfo->pr_dmodel check in the predicate instead. It makes the D code much more readable. > But this isn't documented anywhere I've seen, or more to the point that > the customer has seen. Is this an oversight, or are we missing > something? or should we just avoid doing this at all costs? You don't have to avoid it. You just need to be aware that to interpret user-land data using PID provider probes requires care. Chasing pointers results in ugly, explicit copyins. Handling 64-bit values in 32-bit apps requires joining two 32-bit values in the probe actions. This is just a result of the PID provider's relative simplicity. Nico -- _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org