Hi Nico,
Thanks - that's what I expected, and needed, to hear. Not the best
answer, but consistent with what I'd already figured out.
Ta,
Mark.
On 24/03/2010 02:02, Nicolas Williams wrote:
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
