This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug translator/14924] warn on complex $ptr->foo expressions in .return probes


https://sourceware.org/bugzilla/show_bug.cgi?id=14924

--- Comment #8 from Martin Cermak <mcermak at redhat dot com> ---
Created attachment 9622
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9622&action=edit
possible patch

(In reply to Frank Ch. Eigler from comment #7)
> IMHO, we should warn even for plain  .return {$var}  constructs

Attached patch does that. I've -p2'd all the return probes and it looks fine
except one problem: For example:

Probe signal.send.return is only defined in the tapset for systemtap_v <=
"2.1".  So, when a user runs modern stap without --compatible, and her script
refers to probe signal.send.return, then this probe gets constructed using
probe signal.send, which actually is defined in the tapset. But since it is an
"entry" probe used as a "return" probe, the translator shows misleading warning
like this:

=======
$ stap --poison-cache  -e "probe signal.send.return {exit()}"  -p2 >/dev/null
WARNING: confusing usage, consider @entry($t) in .return probe: identifier '$t'
at /usr/local/share/systemtap/tapset/linux/signal.stp:76:28
 source:     task = @choose_defined($t, $p)
[ ... stuff deleted ... ]
=======

Let's list the linux/signal.stp:76 neighbourhood:

=======
  73 probe __signal.send.send_sigqueue = kernel.function("send_sigqueue")       
  74 {                                                                          
  75     name = "send_sigqueue"                                                 
  76     task = @choose_defined($t, $p)                                         
  77     sig = @choose_defined($q->info->si_signo, $sig)                        
  78     sinfo = @choose_defined($q->info, 0)                                   
  79     shared = 0                                                             
  80 %( systemtap_v <= "2.1" %?                                                 
  81     send2queue = 1                                                         
  82 %)                                                                         
  83 }
=======

So, that's misleading, since adding @entry() there would break the probe.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]