DTrace/ARM .. some progress at last

After spending a long time and effort trying to get FBT to work, I have
a working example:

/home/fox/src/dtrace@raspberrypi: uname -a
Linux raspberrypi 3.6.11 #4 Mon Mar 18 21:26:49 GMT 2013 armv6l GNU/Linux
/home/fox/src/dtrace@raspberrypi: build/dtrace -n fbt::sys_chdir:entry
dtrace: description 'fbt::sys_chdir:entry' matched 1 probe
CPU     ID                    FUNCTION:NAME
  0   3170                  sys_chdir:entry
^C

My prior attempts at intercepting the invalid opcode handler failed.
I dont fully understand why, but having gotten this far, I may have a better
understanding about what I did wrong to be able to tackle this again.
The prior attempt tried to come in at a low level. The current
attempt does what kprobes does and uses the register_undef_hook() kernel
function to add a handler for invalid opcode manipulation. This is nicer,
in that it is pure C code - no assembler, but it not so good because it
will preclude tracing certain low level functions.

This example above is special - the ARM does not (does it?) have single-step
support, so in order to handle FBT probes requires an ARM emulator
to handle the continuation of an FBT probe. The code in dtrace handlers
the PUSH instruction on entry to sys_chdir. (sys_chdir was chosen as
its easy to fire it, on demand, and theres no background activity misfiring
it except, when I want it to).

The next step is to start advancing the ARM emulator (I have been studying
what kprobes does to get an idea of how complex this is - it is complex,
but it only needs certain instructions to be emulated - those on entry
and exit of a function - not every instruction. Now I can start looking
at all entry points to see what are the common functions).

I have a realisation that this only targets the raspberrypi cpu (armv6l)
and fully expect any other system to require more hard work to handle the
various ARM chipsets, along with ARM64. My only other target ARM chip
is a galaxy note 2 (Android), so eventually, the goal is to try and
get this working on Android, but thats a step later.

(The sources arent released yet - theres no milage in doing so, but I will
release them in a few days or weeks [most likely], when I feel the
substance of the ARM/DTrace port is more functional).

In case anyone asks: Why am I doing this? Because I can. No more to it than
that. If anyone wants to pay me or send me appropriate hardware, am happy
to consider prioritising the work, but theres no guarantee progress is fast.

BTW, I created my first "Hello world" Android app the other day. It didnt
work (some cross compilation issue). I want to solve that so I can get CRiSP
running on Android. (CRiSP actually works quite nicely with the ConnectBot
ssh emulator and running remotely; but thats not really very useful).

Post created by CRiSP v11.0.16a-b6552