Re: Hitachi djprobe mechanism

[Mathieu Lacage <Mathieu dot Lacage at sophia dot inria dot fr>]

On Mon, 2005-08-01 at 09:17 -0400, Mathieu Desnoyers wrote:

[snip]

> > If I read the djprobe documentation well and if I assume that
> > inserting/removing the probe can be done safely, independently of how
> > many bytes I overwrite in the source function, the rules, for now, are
> > rather simple.

[snip]

> If you follow the discussions on the system tap mailing list, you will find out
> that any instruction smaller that 5 bytes is a bad thing to overwrite.
> (interrupts and preemption problems, as well as cpu instruction cache coherency)
> Some of those cases (interrupts and instruction cache coherency) only shows on
> SMP machines (assuming the overwriting code would return in the modified path
> through an interruption on UP, which is plausible).

I specifically stated above that I assumed that inserting and removing
the probe was a problem solved. Maybe this assumption is just not
workable (even with a very high runtime cost) without assuming also
overwritten instruction lengths bigger than 5 bytes. I have no idea but
I am must say that I am not really interested in the process of
inserting and removing the probe. I am merely trying to figure out what
the other constraints on probe location look like.

Right now, I think the only constraint you have for the placement of
probes is that you need to insert the probe in a basic block which is
bigger than 5 bytes. This should solve the problem raised by karim:

        if (...)
                goto label;
        <more code>
        single_byte_asm_instruction_code();
label:
        foo();

The problem boils down to calculating the basic blocks for a function
and then calculating whether or not this basic block is large enough to
insert a jump in it (even if you want to probe the end of the bb, you
can insert the probe at the start of the bb because, by definition, all
instructions in the bb will execute if any of them executes)

Of course, it should be quite possible to work around this limitation by
performing relocation on multiple basic blocks (as suggested by Karim in
one of his emails) but I am not sure the complexity of doing this would
really gain much. 

The real question is: "how many basic blocks in a program are smaller
than 5 bytes ?" and I suspect that the answer will look much better than
the statistics reported by Karim on the size of instructions. I will
send a small script here which evaluates this asap.

regards,
Mathieu
--