Monday, 22 April 2013

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 entryprobes are handled - so I can ensure we only trap what is supported bythe emulator. Supporting:

push {r4, lr}

is sufficient to handle a large number of entry points (that pushinstruction approximately handles all single arg functions). Bygeneralising to handle any PUSH instruction, we can handle a lot more, andso on. (In ARM assembler, you can push any permutation of all 16 registerson 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. Internalprints 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 backto the invoking process, but the trace is not logical. I have to tryreally hard to push all preconceptions from my mind and look for the"unobvious". Hopefully, I can find it (I dont think any debugging toolcan help, unless I could somehow trace execution forwards, at the instructionlevel on the third chdir() syscall).

If I can solve this, then it opens up FBT to handle as many sequencesas 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 causea 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