This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Hitachi djprobe mechanism


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]