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: [RFC] Design + prototype: Multiple handler sets per probe address


Roland McGrath wrote:
It seems to me you could handle multiple kprobes along with multiple
jprobes.  You just need to maintain some state about the probes in progress
rather than relying on normal control structures like calling all the
routines in a for loop.  When jprobes_return causes longjmp_break_handler
to run, kprobes then pick up where it left off and run the next probe.

This seems like it might be a better way to go about things for multiple
kprobes anyway.  You don't really want to run the break_handler for all the
probes in the aggregate because there was a breakpoint in one.  You should
just run the break_handler for the one that was running.  If you maintain
that state (i.e. current_kprobe), then that's all you need to pick up the
list walk there after a break_handler returns for some probe.  If you do
that in the general case of kprobes with a break_handler, then jprobes
falls out.

Yes this is an option I am considering with the design (see [RFC]... take2 therad) I posted on 6th April and Prasanna's layered approach. In fact, we also may, depending on how we decide to handle faults, need to maintain a "current_kprobe" when running the aggregate_handlers so as to run just the appropriate fault_handler and that can be used to run just the appropriate break_handler too.

In any case, the longjmp_break_handler will reset the stack and regs to
the expected state so other kprobes don't fall over.

Thanks,
Ananth


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