Re: Hitachi djprobe mechanism

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

[trimming CC list again]

On Mon, 2005-08-01 at 16:31 -0400, Karim Yaghmour wrote:
> Satoshi Oshima wrote:
> > step 2: safety check;
> >          make sure that all CPUs don't run on the code that will
> >          be replaced with jmp instruction (also check whether stack
> >          include EIP of the code which is subject to replace)
> 
> Please explain exactly how you will make sure that there is no pre-existing
> reference to any of the replaced instructions, whether it be on the stack
> or elsewhere. Consider a system that has many thousands of processes running
> in parallel on different CPUs.
> 
> Also consider that you may find things on the stack that look like address
> references to the range you wish to replace, but are actually valid data.

I have probably missed something here but I would appreciate if you
could point me to my mistake.

The only reasonable reason why you would see the EIP of an instruction
somewhere on the stack is because it was pushed there as:
  - a function argument as a function callback.
  - the return address of a call statement.

In both cases, these EIPs represent the start of a basic block which
means that, if you follow my earlier suggestion of calculating carefully
the complete basic-block tree of your functions to avoid inserting
probes at basic-block boundaries, you should be able to always ensure
that these EIPs stay valid. At worst, if they are used by some piece of
code, the code will jump back to the old basic-block which will
immediately jump to its probe because its first instruction is the probe
jump.

regards,
Mathieu
--