This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: process().statement() doesn't seem to work
- From: Josh Stone <jistone at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Zoltan Kiss <zoltan dot kiss at linaro dot org>, systemtap at sourceware dot org
- Date: Fri, 10 Jul 2015 15:59:09 -0700
- Subject: Re: process().statement() doesn't seem to work
- Authentication-results: sourceware.org; auth=none
- References: <558DA0E3 dot 9060904 at linaro dot org> <5591D73E dot 3010309 at redhat dot com> <y0mio9te67a dot fsf at fche dot csb>
On 07/09/2015 07:50 AM, Frank Ch. Eigler wrote:
>
> jistone wrote:
>
>> [...] The behavior of .return variables is often suprising to
>> people. [...] But we cheat a little and also save values from the
>> *entry* of the function for you. That's most useful for the $$parms
>> string or any of the individual parameters. [...]
>
> Should we deprecate this behavior, now that the superceding @entry()
> construct is itself quite old?
As in, make .return $var an error and require explicit @entry($var) ?
@entry is inferior in one important way: it doesn't know the type of the
thing being saved until later, in the type resolution phase. We might
be able to shortcut this for special cases, including $var, but a
general expression could end up as a string or a long.
For instance, in dwarf_var_expanding_visitor::visit_entry_op it must
always use gen_mapped_saved_return, with a global map and all the
indexing and locking that entails, rather than the nicer kretprobe data
pouch via gen_kretprobe_saved_return. Maybe that could be redesigned to
not care about the type so soon, but for now it needs to know up front.
The autocast dwarf types also fail through @entry, PR18579.
https://sourceware.org/bugzilla/show_bug.cgi?id=18579