From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1895 invoked by alias); 6 Jan 2006 21:35:03 -0000 Received: (qmail 1888 invoked by uid 22791); 6 Jan 2006 21:35:02 -0000 X-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_ABUSE,RCVD_IN_BL_SPAMCOP_NET,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e35.co.us.ibm.com (HELO e35.co.us.ibm.com) (32.97.110.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jan 2006 21:35:01 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k06LZ0ZB006314 for ; Fri, 6 Jan 2006 16:35:00 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k06LaxA8172732 for ; Fri, 6 Jan 2006 14:37:00 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k06LYxUQ010948 for ; Fri, 6 Jan 2006 14:34:59 -0700 Received: from dyn9047018079.beaverton.ibm.com (dyn9047018079.beaverton.ibm.com [9.47.18.79]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k06LYxu1010931; Fri, 6 Jan 2006 14:34:59 -0700 Subject: Re: function parameter access in kretprobe handler From: Jim Keniston To: Roland McGrath , SystemTAP In-Reply-To: <20060106094023.AB6E0180B7C@magilla.sf.frob.com> References: <20060106094023.AB6E0180B7C@magilla.sf.frob.com> Content-Type: text/plain Organization: Message-Id: <1136583298.2849.33.camel@dyn9047018079.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: Fri, 06 Jan 2006 21:35:00 -0000 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q1/txt/msg00053.txt.bz2 On Fri, 2006-01-06 at 01:40, Roland McGrath wrote: > This subject has been discussed here before. I'll try to summarize. > > The DWARF information that's used for $foo variable accesses in theory > always says for each PC either how to get the right value, or that it > cannot be gotten. > > kretprobes trap at the actual return site, after the function epilogue. > At this point it is almost never possible to recover local variables like > arguments. However, since kretprobes are some special magic, there isn't > a correct PC that the translator can use as context for getting $foo > locations from DWARF. If you set a normal kprobe at the end of a > function, such as at the beginning of its epilogue, then it may be > possible that more local variables are accessible. However, there is > never any guarantee that variables will be accessible if they are dead in > the program at that point (which all are at the end of the function), and > of course those local variables that were originally arguments may no > longer have the original values passed in. > > The only completely reliable way to get a function's arguments in a return > probe is to actually get them at function entry and store values for later > use in the return probe. Kprobes support for this is pretty easy. Kevin wrote and tested a patch that adds a user-defined "entry_info" pouch to a kretprobe_instance. An accompanying handler, entry_handler, is called to copy info (e.g., arg values) into the pouch at function entry. When the function returns, the return-probe handler has access to these values: http://sourceware.org/ml/systemtap/2005-q3/msg00593.html Frank was lukewarm regarding this idea, I think mostly because DWARF can tell you how to find arg values at the end of the function prolog, but not right at entry to the function: http://sourceware.org/ml/systemtap/2005-q3/msg00599.html Finding the arg values on function entry is theoretically very straightforward -- each architecture's ABI spells it out -- except that for some architectures, declarations such as fastcall and asmlinkage map to regparm attributes that alter where args are passed. And it's my understanding that DWARF doesn't provide a function's regparm value. That, I think, is the main obstacle to SystemTap using jprobes. Correct me if I'm wrong. Jim > Right now, you just do that by hand by writing > multiple probes and using global variables; it's not very pretty. There > has been some mention of a more automatic version of this feature wherein > e.g. $foo references to arguments mentioned in a return probe would > produce an implicit entry probe to collect those values and provide them > to the return probe script code, without using any unsightly global > variables at the systemtap language level. Noone has pursued this idea much. > > > Thanks, > Roland > >