This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: visit_target_symbol() for derived_probes
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: William Cohen <wcohen at redhat dot com>
- Cc: <systemtap at sourceware dot org>
- Date: 22 Aug 2006 14:05:48 -0400
- Subject: Re: visit_target_symbol() for derived_probes
- References: <44EB22FD.7060508@redhat.com>
wcohen wrote:
> [...]
> global handle
> global cycles_start, cycles_end
> probe perfmon.counter("CPU_CLK_UNHALTED") {handle= $counter}
^^^
> probe begin { cycles_start = read_counter(handle) }
> probe end
> {
> cycles_end = read_counter(handle);
> elapsed = cycles_start - cycles_end;
> printf("%d cycles\n", elapsed);
> }
Yeah, plausible.
> I have been looking at how target symbols and $return are handled in
> the dwarf_derived_probe. [...]
Look also at marker_derived_probe for another implementation with a
different flavour.
> typeresolution_info::visit_target_symbol (target_symbol* e) [...]
> throw semantic_error("unresolved target-symbol expression", e->tok);
Yes, this detects the failure-to-process scenario.
> How is the node in the tree generated for the target symbol?
The target_symbol node is generally replaced with a synthesized getter
or setter function call: mark_var_expanding_copy_visitor::visit_target_symbol
- FChE