I've gotten my RaspberryPi VM to run from a kernel I have built,
which means I can now load dtrace into the ARM kernel and continue
One silly issue I have hit is module/divide arithmetic for 64-bit
numbers. ARM, being a classic RISC chip, doesnt have a divide instruction
but the kernel nicely hides this for you. In most cases, divide-by-a-constant
is handled by the compiler via various optimisations.
At the moment, theres a few pieces of code where divide/modulo are
not by a constant the compiler can see, which results in the compiler
generating calls to maths helper functions. On the i386/x64 architectures,
this is handled by dtrace mapping to the appropriate mechanisms to
call the do_div() function.
On the ARM, its different - and confusing enough (given the differing
ARM architectures) to not be working yet; so when dtrace is tracing
to its own internal log buffer (which I need to debug the GPF's I am triggering)
its a nuisance, because decimal numbers come out wrong.
Its interesting poking around the kernel code at the do_div64() macros
and the printf type code, as the kernel makes good attempts to leverage
native CPU features, or emulate, in the case of the ARM/Risc instructions,
to get a reasonable performance.
Theres lots of ways to do divide, without actually doing a divide
(many algorithms in the kernel). What is a nuisance is debugging the
mechanism I am using to call these, as its mostly crashing the kernel,
and difficult to do in user space (in user space, it can work, because
the compiler "just works", which doesnt help prove what I am doing
is correct in the kernel).
Still a way to go, but at least I can load the driver.