DTrace/ARM update

I am getting ready to push out a new DTrace release, which includes
the ARM support. I enclose in this blog post, a copy of doc/ARM.txt
which explains what works and what does not.

--- doc/ARM.txt

DTrace can run on the ARM processor. The ARM CPU exists as a number
of variants, from tiny embedded CPUs, to full blown general purpose
CPUs, commonly found in smart phones and other systems. As of this writing,
ARM/64 is coming.

The earliest ARM processors had limited memory support (many instructions
refer to 26-bit addresses); later processors can support 4GB of memory.

The ARM port of DTrace has been done in a KVM virtual machine, targetting
a custom kernel (Debian/Wheezy and 3.6.11 kernel) for the RaspberryPi,
which is a ARMv6 architecture kernel and CPU.

This specific kernel was chosen, simply so that I could tally the kernel
binary with the source code, in order to clarify how the ARM
architecture worked, and specifics of debugging probe functions.
In theory DTrace should work on earlier and later kernels.

As of this writing, SMP kernels have not been tried. Almost certainly,
DTrace will not work on an SMP system (because I have not validated
the xcall CPU code). It *might*, but I am suspect it will not, and there
is a need to verify this.

This port relies on the register_undef_hook() kernel function
to intercept the FBT probes. FBT probes are implemented by
using an undefined-instruction and handling the traps they generated.
This is different to x86, where 0xCC (INT3) and single-step mode is
used to manage probes which are taken. (ARM appears not to have
single-step mode execution).

The file toxic.c is updated to avoid those parts of the
interrupt fabric which are needed for the probes to fire, so we are
more conservative in what can be probed (this mostly wont matter
to most people). "dtrace -n fbt:::" is *safe*, as far as my testing
is concerned, and the toxic probe functions reflect areas which have
caused trouble. It is possible that more research is needed if you
attempt to step out of what I have personally tested.

Summary:

   * ARMv6 architecture only
   * No support for Thumb mode (or, not tested with Thumb user apps)
   * Validated against RaspberryPi
   * Not validated against Android
   * Not validated on SMP
   * Not validated on ARM/64
   * Not validated on < ARMv6 or > ARMv6

   * FBT works
   * USDT has not been validated
   * SYSCALL is dummied out - to be fixed in subsequent release

Future:

Some of the items above will be addressed in future versions, especially
SYSCALL, followed by SMP, and eventually, Android.


Post created by CRiSP v11.0.16a-b6555