dtrace discuss - Mar 2010 - Using DTrace in 32-bit to handle 64-bit parameters [72631230]

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            __|

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
--

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