From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13273 invoked by alias); 1 May 2006 21:17:36 -0000 Received: (qmail 13266 invoked by uid 22791); 1 May 2006 21:17:36 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mga03.intel.com (HELO azsmga101-1.ch.intel.com) (143.182.124.21) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 01 May 2006 21:17:34 +0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 01 May 2006 14:17:10 -0700 Received: from scsmsx332.sc.intel.com (HELO scsmsx332.amr.corp.intel.com) ([10.3.90.6]) by azsmga001.ch.intel.com with ESMTP; 01 May 2006 14:17:10 -0700 X-IronPort-AV: i="4.04,169,1144047600"; d="scan'208"; a="30133100:sNHT38576615" Received: from scsmsx403.amr.corp.intel.com ([10.3.90.18]) by scsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 14:17:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: Tapset difficulties w/ pointers Date: Mon, 01 May 2006 21:17:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tapset difficulties w/ pointers thread-index: AcZsh2MKcEsJGeJ6RtqqOxqp0y2KyQAzl/xAAAOtEfA= From: "Stone, Joshua I" To: X-OriginalArrivalTime: 01 May 2006 21:17:09.0750 (UTC) FILETIME=[9B5F2960:01C66D64] 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-q2/txt/msg00289.txt.bz2 Forgot to CC the mailing list... On Monday, May 01, 2006 12:55 PM, Stone, Joshua I wrote: > On Sunday, April 30, 2006 11:53 AM, Frank Ch. Eigler wrote: >> We don't have to return correct answers to trick questions, just >> avoid hurting the system. Dereference operations in exposed >> embedded-C code can be channeled through the same deref() macro used >> by $target variable expansions, which aims to catch ordinary faults. >=20 > OK, so is this how task_pid() should look? >=20 > function task_pid:long (task:long) %{ /* pure */ > struct task_struct *t =3D (struct task_struct *)(long)THIS->task; > THIS->__retvalue =3D deref(sizeof(t->tgid), &(t->tgid)); > goto out; > deref_fault: > CONTEXT->last_error =3D "pointer dereference fault"; > %} >=20 > This seems to work, but is it safe from all contexts? >=20 > There seems to be a bug in the deref macros in loc2c-runtime.h -- the > temporary used to capture the value is an intptr_t, which was > #defined to long. A long is 32-bit on i386, so deref(8,addr) will be > truncated, and probably corrupt the stack with the rest of the value. >=20 >>> One solution is to "hide" task_pid(), perhaps by renaming it to >>> __task_pid(), and then have the tapset provide variables for pid, >>> tid, etc. and rely on the compiler to elide those that are unused. >>> [...] >>=20 >> This style should work well with recent optimizer tweaks. >=20 > If we can make the dereferencing safe, then I would prefer leave it > exposed. That way I can have a task_parent function, and let the > user query info about the parent, grandparent, etc.=20=20 >=20 >=20 > Josh