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
[email protected]
