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






mathieu lacage <Mathieu.Lacage@sophia.inria.fr> wrote on 08/10/2005
19:33:13:

> 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 ?
>

So the assumption here is that:
1) we are dealing with non-optimized code.
2) we are dealing with gcc generated code.

Whilst it's unlikely that compilers other than gcc are used, it's not
impossible - e.g. Intel's IA64 compiler. And the likelihood of non-gcc
compilers increases when we consider user-space probes. But also it is
possible that we might want to probe handcrafted assembler code in
kernel-space.

Are we able to guard against these exceptions automatically, or do we have
to disallow a jmp probe on instructions less than the jmp size?
You realise that if we get the probing mechanism wrong we will cause
bizarrely unpredictable results.


> 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.
>

Not sure about that. I think I can find an example of c-code for which it
is impossible to determine the function boundaries from the assembler code,
but looks perfectly reasonable from the C perspective.



> 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]