From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28980 invoked by alias); 28 Apr 2010 11:52:46 -0000 Received: (qmail 28851 invoked by uid 48); 28 Apr 2010 11:52:27 -0000 Date: Wed, 28 Apr 2010 17:36:00 -0000 From: "fche at redhat dot com" To: systemtap@sources.redhat.com Message-ID: <20100428115225.11550.fche@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug translator/11550] New: dynamic probe point parameters X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q2/txt/msg00222.txt.bz2 A request from IRC suggests a useful construct: where watchpoint probes' addresses are computed on the fly. Syntax could look like this: global addr probe kernel.data(addr).length(300) { } probe kernel.function("something") { addr = $myaddr } so each time "something" hits, the address would be recomputed and the hardware breakpoint probe reset. This would require the same sorts of constraints on the globals as already enforced for probe point conditionals. This would also require the sorts of on-the-fly registration/unregistration logic as pending for PR10995. Some probe point types may permit such parametrization in several fields. The dwarf ones would probably not support it in any slot, but kprobe.function(SYM), timer.s(NN) could. -- Summary: dynamic probe point parameters Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: translator AssignedTo: systemtap at sources dot redhat dot com ReportedBy: fche at redhat dot com BugsThisDependsOn: 10995 http://sourceware.org/bugzilla/show_bug.cgi?id=11550 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.