Hi all,
OK, so this at first looked like a clear cut "Don't do it, or at worst
handle the results" issue my customer has come to me with, but the more
we discuss it, the more it looks like we should have better ways of
dealing with this issue.
> We have user defined dtrace probe points in the application which use
> as parameter 64 bit values:
>
> provider adv {
> probe myprobe(int64_t messageId);
> };
>
> These values are not correctly visible in the dtrace script.
> In theory the following dtrace script should work:
>
> adv$1:::myprobe
> {
> printf("\n%016llx", arg0);
> }
>
> In reality this only works if the application process which uses the
> trace point
> is compiled as 64 bit process.
> When compiling the application as 32bit process, the input parameter
> "messageId"
> is transferred to parameters arg0 and arg1.
>
> On SPARC the correct value for messageId in the 32bit process would
> be:
> (arg1 << 32) | arg0
> On X86 the correct value for messageId in the 32bit process would be:
> (arg0 << 32) | arg1
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.
They have libraries compiled in both 32- and 64-bit, they have loads of
code, it's complex but it works. And this can't be the only place this
happens. If DTrace is using 32-bit variables, and is handed a 64-bit
value, then the text of the docs:
> http://docs.sun.com/app/docs/doc/817-6223/chp-variables?a=view
>
> DTrace Builtin Variables
> int64_t arg0, ..., arg9
>
> The first ten input arguments to a probe represented as raw 64-bit
> integers. If fewer than ten arguments are passed to the current probe,
> the remaining variables return zero.
is somewhat confusing, as now that 64-bit value is taking up *2* args,
not the one you'd expect.
This is messy, it's confused this customer so it must be confusing
others. I'm old, so I'm looking at these abstraction layers as hiding
what has to go on underneath anyway, and would just get on with it. The
customer is coming around to that way of thinking:
> Small example:
> provider adv {
> probe myprobe(int64_t param1, int32_t param2, int64_t
> param3);
> };
>
> 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);
> this->param2 = (curpsinfo->pr_dmodel == PR_MODEL_LP64) ?
> arg1 : arg2;
> this->param3 = (curpsinfo->pr_dmodel == PR_MODEL_LP64) ?
> arg2 : (`utsname.machine == "i86pc") ? ((arg4 << 32) |
> arg3) : ((arg3 << 32) | arg4);
>
> /* probe description */
> printf("\nparam1=%016llx param2=%x param3=%016llx",
> this->param1, this->param2, this->param3);
> }
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?
Ta,
--
| o o Software Support Engineering,
/v\ark R. Bowyer. SPARC House, Guillemont Park,
`-' Minley Rd, Blackwater,
Tel: +44 (0)1252 420691 Camberley, SURREY, GU17 9QG
Fax: +44 (0)1252 421658 United Kingdom __|
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
