This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: Hitachi djprobe mechanism
On Tue, 2005-08-02 at 17:32 +0200, Mathieu Lacage wrote:
> [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
I meant "across basic-block boundaries" and not "at basic-block
boundaries".
> 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.
Mathieu
--