This is the mail archive of the systemtap@sources.redhat.com 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: [Fwd: Re: [PATCH] Return probe]





Jim Keniston <jkenisto@us.ibm.com> wrote on 19/04/2005 19:15:55:

> On Tue, 2005-04-19 at 09:29, Richard J Moore wrote:
> >
> >
> > Do you take into account the problems I documented in my technical
> > disclosure on implementing return points?
>
> I don't believe I've seen your disclosure, but yes, we've taken these
> problems into account.
>
> > These are:
> >
> > 1) What happens if the return address is modified by the called program
> > (legitimately or otherwise)?
>
> Assuming it's modified after the entry probe has been hit and processed,
> the modified return address will be used.  The trampoline won't be hit,
> the return handler won't be run, and we'll leak a kretprobe_instance
> object.  If we eventually leak all that kretprobe's kretprobe_instance
> objects, the return handler for that kretprobe won't run any more, and
> the kretprobe's nmissed counter will grow accordingly. Nothing else will
> be affected.

My proposal doesn't cause a leak. And this is a real possibility,
especially with ptimized funcotin returns where, say a return code is used
to index into a branch table. zSeries uses this all the time. Assembler
programmers would as a matter of course code a table of branch (jiump)
instrictions and jump to the table, indexed by the retun code.

>
> > 2) What happens if a multi-level function return takes place? This is
quite
> > possible with optimization and some finite-state-machine
implementations.
>
> If the number of calls doesn't match the number of returns, it's a
> problem.  We have added code to handle the possibility of probed
> functions being active when the stack is discarded at exec or exit time.
> We restore the original RAs to the stack (in case they're needed) and
> recycle the unused kretprobe_instance objects.  I don't know of any
> other situation where # calls != # returns.

I've seen situations where routines are "stacked" and the jump from one to
another,  down the stack until the last routine is executed, which then
returns. An example is CICS under zSeries, which is a pseudo-conversational
transaction processor. But you also see this when the compiler optimizes
returns.

>
> > 3) What happens in the function call is register based (PPC, zSeries
etc,
> > optimized IA32 etc...)
>
> As previously described (2/18/05, 3/11/05), this should work for ppc64,
> or any architecture where the RA is in a predictable register or memory
> location when you hit the first instruction of the function.  I don't
> know the zSeries architecture well enough to comment.  If there are
> optimizations on other architectures such that we can't currently
> predict where the return address is, we'll have to get smarter or ask
> the user for help.

On zLinux they use the same conventions as zOS - that is to call a routine
using
BALR 14,15

This branches to the routine whose address is in reg 15 and stores the
address of the next instruction in reg 14. Note: zSeries is not a
stack-based architecture.

>
> The one problem I see for ppc64 is that of restoring the original RAs to
> the stack (unless we can reliably predict where in the stack frames
> they're saved).  This would be a problem only when probing functions
> that (possibly indirectly) call flush_thread() or exit_thread() and
> actually return.
> >
> > - -
> > Richard J Moore
> > IBM Advanced Linux Response Team - Linux Technology Centre
> > MOBEX: 264807; Mobile (+44) (0)7739-875237
> > Office: (+44) (0)1962-817072
>
> I believe that all these limitations can be documented along with other
> kprobes limitations, and don't seriously affect the usefulness of the
> feature.
>
> Jim
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]