DTrace/ARM

Progress on the ARM port of DTrace continues. At the moment,
the driver loads, and reloads into the kernel. (I was crashing on a
reload, which is annoying - having to keep rebooting as I fine tune
the code). Its still a skeletal ARM port, but I can now do:

$ dtrace -n tick-1s

and the expected thing happens. Thats a huge relief - the core of DTrace
just works.

Next was some small fixes for /proc/dtrace/fbt - to see the state
of the available FBT probes (and specifically the instructions
and patch values). A key difference of ARM vs x86 is that ARM is
a 32-bit cpu - all instructions are 32 bit wide, and not variable
like on x86 (which allows 1-byte or more instructions). Because
instructions are 4-bytes wide, some changes to the key data structure
(intr_t) is needed to handle the 4-byte wide value and apply that
to, e.g. the FBT driver.

ARM presents many challenges: the first is that there are so
many variants. I am targetting the ARMv6 architecture available on
the RaspberryPi, and uses a hand built kernel running in a qemu VM.

At present I dont have a /proc/kcore, which is a nuisance - its useful
using this to examine inside the kernel, e.g. disassembly or proving
if a probe is what I expect it to be. (I can work around that easily).

Additionally, this is a single CPU kernel - no SMP. (I believe
I found a bug in the Solaris DTrace where the maximum number of CPUs vs
the kernel, is concerned; Solaris supports 32 i386 CPUs or 256 amd64
CPUs - if the max CPUs are configured, theres some out-by-one maths going
on in the buffer snap code, which causes dtrace to abort early in its
work. On ARM I hit this because NCPU==1, and the code tries to look
at cpu#0 and cpu#1).

Now, I am ready to start handling FBT. I can get DTrace to plant probes
on entry, but the return probes are broken, because its using the x86
instruction disassembler and not an ARM specific one (easy to fix, when
I am ready).

But before I allow an FBT probe, I need to intercept the ARM single
step and breakpoint interrupts. I found this page as a useful hint/starter
to get me to the right place to locate what I am after...

http://pankaj-techstuff.blogspot.co.uk/2007/11/story-interrupt-handling-in-linux-2611.html

First step is to put a "no-op" interrupt handler in place to prove
I am doing the right thing. I am not an ARM assembler expert, and am
using gcc -S and ARM instruction references on the net, to get me
closer to one.

Once this is done, then the syscall mess (in my code) can be looked at -
the systrace.c code is full of hacks and quirks for i386/amd64 and
most/none of this is relevant for ARM.

After that, we would be mostly done. (USDT will require some work,
but USDT is more leasurely than core driver work).

The dtrace, available at my site or github doesnt have all the ARM
updates, so hold off for a while before expecting this to work. I will
update the blog when I feel its more ready for primetime.


Post created by CRiSP v11.0.15a-b6543