Number 3

I wrote last time about getting the first ARM based FBT probe working.
In extending the ARM emulation, I started cleaning up the way the entry
probes are handled - so I can ensure we only trap what is supported by
the emulator. Supporting:

push {r4, lr}

is sufficient to handle a large number of entry points (that push
instruction approximately handles all single arg functions). By
generalising to handle any PUSH instruction, we can handle a lot more, and
so on. (In ARM assembler, you can push any permutation of all 16 registers
on the stack in one instruction - the registers are bit encoded).

However, I hit a problem. Scaling back, I found that:

$ bash
$ cd
$ cd
$ cd

would cause bash to get a segmentation violation. Why its the third chdir -
I havent figured out. A simple test app doesnt show this. Internal
prints and close code review doesnt make it obvious what I am doing wrong,
even if I distill this down to a basic trap handler.

It seems like something is being corrupted on return back
to the invoking process, but the trace is not logical. I have to try
really hard to push all preconceptions from my mind and look for the
"unobvious". Hopefully, I can find it (I dont think any debugging tool
can help, unless I could somehow trace execution forwards, at the instruction
level on the third chdir() syscall).

If I can solve this, then it opens up FBT to handle as many sequences
as I care to emulate - but, because of the way ARM probes are implemented
(by me), I will have to be careful of some functions which could cause
a recursion issue (which doesnt exist on the x86 DTrace implementations).

Nobody said this was gonna be simple...

Post created by CRiSP v11.0.16a-b6552