kernel, via the module part of a probe name. We set this to "x32" or
"x64". By default, you would wildcard this field:
$ dtrace -n syscall::open:
but now you can elect to monitor, e.g. just 32-bit syscalls:
$ dtrace -n syscall:x32::
Took me a while to figure out how to determine if we are on a 32-bit
syscall or 64-bit one. Technically, its not the syscall which is 32 or
64 bit, but the process (actually, current thread). I had a silly in the
code so that no 32-bit processes were being trapped.
In examining the kernel code, theres various things that could be done
by a process which might confuse the kernel. Most of the kernel makes
no distinction between a 32-bit app and a 64-bit one. Things
like the ELF magic part of the initial a.out file can be overwritten,
without transforming a process from one more to another. The later kernels
cache a bit to indicate which mode its in, but its rarely consulted.
There is a personality field in the thread structure, so it would
be definitely interesting to change this to try and flip from
32 to 64 bit modes.