Re: Hitachi djprobe mechanism

[mathieu lacage <Mathieu.Lacage@sophia.inria.fr>]

hi richard,

 >I don't see why block analysis is helpful. Unless one can guarantee fixing
 >up all jmp to an instruction following the probed instruction then we
 >simply cannot allow jmp to overlay anything smaller than its length.

Block analysis should allow you to detect all jmp targets which become 
the boundaries of the blocks. Thus, inserting any instruction in any 
block is harmless provided you do not cross the block boundaries because 
a jump target cannot fall _within_ the block. Does this answer your 
implicit question about the usefulness of the block analysis ?

Of course, the question becomes: how do you detect all jmp targets when 
some of them are indirect jumps. I did spend quite a bit of time trying 
to answer this question. So far, it is clear to me that non PIC code 
contains very few indirect jumps so you should be able to get close to 
90% function coverage with a simple block analysis taking into account 
only direct absolute and relative jumps. However, the hard part comes 
when you want to deal with functions which contain a switch statement. 
Being able to parse this last 10% of functions represents a lot of more 
work than what can be achieved with simple analysis.

The simple perl analysis code can be useful if you want to convince 
yourself about the figures above. I also wrote some prototyping code to 
familiarize myself with the x86 ISA: I think the code should be able to 
correctly parse and report direct jumps as well as their targets. I have 
stopped efforts in this direction since I started looking into the 
harder question of indirect jumps. I believe that an answer to the 
indirect jump question requires a real analysis of the code which means 
being able to perform constant propagation as well as dead code 
elimination passes on an intermediate representation of the code to be 
able to infer the location of the indirect jump tables as well as their 
size statically. I have a start of a framework to do this sort of stuff 
but nothing of practical interest to anyone.

Note that the above specifically ignores the issue of indirect _calls_ 
because I assume they are not able to call in the middle of another 
function.

For now, you can find my mostly finished C prototype in there: 
http://cutebugs.net/code/bozo-profiler/?cmd=manifest;manifest=fff970e1713fe16f8f637cd2065d2287f1d162d6;path=/libdebug/
Look for the files x86-opcode.c/h. I also started writing 
x86-opcode-print.c/h to debug the previous code but I stopped halfway.

 >So are we agreed that djprobe only operates under x86 on instructions >= 5
 >bytes?

I think this is the safe assumption you could fall back to if you found 
yourself being unable to parse the basic blocks of a function because of 
an indirect jump. Should you think that such a block analysis is useful, 
I can cleanup my parsing code and make it useful enough to detect the 
case where it fails and report all block boundaries otherwise.

regards,
Mathieu