Re: Accessing target variables in return probes (was Re: src ChangeLog tapsets.cxx)

[fche at redhat dot com (Frank Ch. Eigler)]

dsmith wrote:

> [...]  There is no way to know if a return probe has been skipped,
> so in the case of probing a recursive kernel function, the cached
> values can get out of sync.  [...]

In case I didn't put this idea on paper already: one way may be to
also store the thread's current stack pointer somewhere in the
tracking data stream.  If we realize that our "current" stack
pointer is higher than that of the highest-nesting-numbered
saved data record, we could unroll to recover synchronization.

In other words, for each synthetic entry point, also save
   n = (nesting[tid()] ++)
   thread_entry_sp[tid(), n] = regs_sp() # add to tapset if needed
   saved_data_value[tid(), n] = $data

and in the return probe handler,

   first=1
   while (first || (thread_entry_sp[tid(), n] < current_sp) {
     first=0   # a candidate for do/while, n'est ce pas?
     n = (-- nesting[tid()])
     current_sp = regs_sp()
     restored_data = saved_data_value[tid(), n];
     delete saved_data_value[...]
     delete thread_entry_sp[...]
   }

Anyway, just a sketch.  Do you get the idea?


- FChE