This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Hitachi djprobe mechanism
- From: Richard J Moore <richardj_moore at uk dot ibm dot com>
- To: mathieu lacage <Mathieu dot Lacage at sophia dot inria dot fr>
- Cc: systemtap at sources dot redhat dot com
- Date: Sat, 8 Oct 2005 22:56:32 +0100
- Subject: Re: Hitachi djprobe mechanism
- Sensitivity:
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
>
>