Re: process().statement() doesn't seem to work

[Josh Stone <jistone@redhat.com>]

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