dtrace discuss - Jul 2008 - Can DTrace tell me if my process is 32 or 64 bit?

I had a simple D script that looks for use of the DP_POLL ioctl with a long
timeout for any process on the system, but I could not find an easy way to
determine whether to use dvpoll or dvpoll32 structures to do so.  An ugly hack
based upon pointer location/value works, but is clearly unacceptable (this was
in a single probe syscall::ioctl:entry/arg1==0xd001/ ):

nfds = (dvpoll->dp_nfds > 1000000) ?    dvpoll32->dp_nfds :
dvpoll->dp_nfds;

Since I could find no way for DTrace to help me out here I looked at source code
and found that dpioctl takes a mode argument that has a bitmask which will
indicate DATA_MODEL, so I modified the script to use that, which works and
should be stable, but it seems DTrace should provide coders with it''s
own way of determining the data_model to save people such gyrations.  Also,
though this script works fine on S10 FCS SPARC/x86 up to snv_86 (Indiana), it
fails on snv_93 (image updated Indiana - it works on a 32 kernel snv_95 machine
but I haven''t found a 64 bit snv_95 to try it on) with :

dtrace: failed to compile script ./ioctl_DP_POLL.d: line 25: operands have
incompatible types: "dblk_t" != "union"

Is this a known DTrace bug in snv_93 or just more restrictive type checking
(seems like a bug...if not, can someone get the script to work in snv_93?)

Anyway, here''s the script that works on all S10 versions through snv_86
but is more complicated than it would be if DTrace had a mechanism of letting me
know if the binary being traced was 32 or 64 bit :

#!/usr/sbin/dtrace -s
#pragma D option quiet

struct dvpoll    *      dvpoll;
struct dvpoll32  *      dvpoll32;

BEGIN {
     printf("If timeout is -1 or big, you could get hit by bugid
6724237\n");
     prev_timeout = -2;
     prev_fd = prev_nfds = prev_pid = -1;
}
syscall::ioctl:entry /arg1 == 0xd001/ {
     self->fd=arg0;
}
fbt:poll:dpioctl:entry {
       self->bitsize64 = (arg3 & 0x00200000); /* model.h: DATA_MODEL_LP64
*/
}
fbt:poll:dpioctl:entry /self->bitsize64/ {
       dvpoll=copyin(arg2, sizeof(*dvpoll));
       self->nfds = dvpoll->dp_nfds;
       self->timeout = dvpoll->dp_timeout;
}
fbt:poll:dpioctl:entry /!(self->bitsize64)/ {
       dvpoll32=copyin(arg2, sizeof(*dvpoll32));
       self->nfds = dvpoll32->dp_nfds;     /* DTrace broken in SNV_93? */
       self->timeout = dvpoll32->dp_timeout;
}
fbt:poll:dpioctl:entry
/ (self->fd != prev_fd) || (self->nfds != prev_nfds) ||
 (self->timeout != prev_timeout) || (prev_pid != pid) /{
       printf("%s pid=%d/%d calling ioctl(%d, DP_POLL, nfds=%d
timeout=%d)\n",
              execname, pid, tid, self->fd, self->nfds, self->timeout);
       prev_pid = pid;
       prev_fd = self->fd;
       prev_nfds = self->nfds;
       prev_timeout = self->timeout;
       self->fd = self->nfds = self->timeout = self->bitsize64 = 0;
}


--
This message posted from opensolaris.org

You could use curpsinfo->pr_dmodel is a predicate.

probe
/ curpsinfo->pr_dmodel == 1/
{
    32-bit process
}

probe
/ curpsinfo->pr_dmodel == 2/
{
    64-bit process
}


/jim


Bruce Chapman wrote:
> I had a simple D script that looks for use of the DP_POLL ioctl with a long
timeout for any process on the system, but I could not find an easy way to
determine whether to use dvpoll or dvpoll32 structures to do so.  An ugly hack
based upon pointer location/value works, but is clearly unacceptable (this was
in a single probe syscall::ioctl:entry/arg1==0xd001/ ):
>
> nfds = (dvpoll->dp_nfds > 1000000) ?    dvpoll32->dp_nfds :
dvpoll->dp_nfds;
>
> Since I could find no way for DTrace to help me out here I looked at source
code and found that dpioctl takes a mode argument that has a bitmask which will
indicate DATA_MODEL, so I modified the script to use that, which works and
should be stable, but it seems DTrace should provide coders with it''s
own way of determining the data_model to save people such gyrations.  Also,
though this script works fine on S10 FCS SPARC/x86 up to snv_86 (Indiana), it
fails on snv_93 (image updated Indiana - it works on a 32 kernel snv_95 machine
but I haven''t found a 64 bit snv_95 to try it on) with :
>
> dtrace: failed to compile script ./ioctl_DP_POLL.d: line 25: operands have
incompatible types: "dblk_t" != "union"
>
> Is this a known DTrace bug in snv_93 or just more restrictive type checking
(seems like a bug...if not, can someone get the script to work in snv_93?)
>
> Anyway, here''s the script that works on all S10 versions through
snv_86 but is more complicated than it would be if DTrace had a mechanism of
letting me know if the binary being traced was 32 or 64 bit :
>
> #!/usr/sbin/dtrace -s
> #pragma D option quiet
>
> struct dvpoll    *      dvpoll;
> struct dvpoll32  *      dvpoll32;
>
> BEGIN {
>      printf("If timeout is -1 or big, you could get hit by bugid
6724237\n");
>      prev_timeout = -2;
>      prev_fd = prev_nfds = prev_pid = -1;
> }
> syscall::ioctl:entry /arg1 == 0xd001/ {
>      self->fd=arg0;
> }
> fbt:poll:dpioctl:entry {
>        self->bitsize64 = (arg3 & 0x00200000); /* model.h:
DATA_MODEL_LP64 */
> }
> fbt:poll:dpioctl:entry /self->bitsize64/ {
>        dvpoll=copyin(arg2, sizeof(*dvpoll));
>        self->nfds = dvpoll->dp_nfds;
>        self->timeout = dvpoll->dp_timeout;
> }
> fbt:poll:dpioctl:entry /!(self->bitsize64)/ {
>        dvpoll32=copyin(arg2, sizeof(*dvpoll32));
>        self->nfds = dvpoll32->dp_nfds;     /* DTrace broken in
SNV_93? */
>        self->timeout = dvpoll32->dp_timeout;
> }
> fbt:poll:dpioctl:entry
> / (self->fd != prev_fd) || (self->nfds != prev_nfds) ||
>  (self->timeout != prev_timeout) || (prev_pid != pid) /{
>        printf("%s pid=%d/%d calling ioctl(%d, DP_POLL, nfds=%d
timeout=%d)\n",
>               execname, pid, tid, self->fd, self->nfds,
self->timeout);
>        prev_pid = pid;
>        prev_fd = self->fd;
>        prev_nfds = self->nfds;
>        prev_timeout = self->timeout;
>        self->fd = self->nfds = self->timeout = self->bitsize64
= 0;
> }
>
>
> --
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>