From owner-freebsd-dtrace@freebsd.org Tue Dec 20 07:10:51 2016 Return-Path: Delivered-To: freebsd-dtrace@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A950EC89066 for ; Tue, 20 Dec 2016 07:10:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F2E51FB7; Tue, 20 Dec 2016 07:10:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x241.google.com with SMTP id u25so2804851qki.2; Mon, 19 Dec 2016 23:10:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=zo3Ljn3hi66Dpiyq8DeCoqqKoPoRsOcH/LHK3ycGON8=; b=Mms14F7rrciquXnpoDBifNACg2rXZW9o5lAmAalxveshjmcIEsSTG6gc/e6atLDywU CNd/LaUC4LdgEKIehiEOPgE4OIRKWZ2XGsKRD5vVmejFDt0+h0S+GflFnddGHdB8lH1T QB1AgebmYQSIcZw5yc1cG0MWFk+IXzMUt0ercBxMdutgqjMa7gRyYSA/bg+CmXq7fsGJ eMGQeVHPhLLT9/LwhdDDmaLAKGg4DtmkJ8Pim3IYvDlLstXoFIbIm+NexgH39pqYUorp oQuw95sojaSZY6FZoxok3CJm72Ivq3WzYm8XrxCzIubela+CP2UvY6/xr0VT+jWtvVEp Wb2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=zo3Ljn3hi66Dpiyq8DeCoqqKoPoRsOcH/LHK3ycGON8=; b=Uci4/ZDmrU60LgksHzC1KYS+fa8Ri8KZa1F8G/ockR4dJD/HNjIxStzatQgBTVjlt8 LnZpcBlzsrITgRj2kodzRQxGGNb2i/pXokK9kePv4kQ3JBE2sa0YH46M7nWV3VCGSQjp 01XdpGkM6jKZE7K+YAQlS37UoFlqbi0DXH45gxvXtpb4ip+4EIGxVf2+6jzcfpTuC7dY rJbtkY+gsOtfq1Zxu1p+2U/++ThyOEa0EsOnohS0gKDuUdcyXhGey6msXMVKY/NMtqp/ JAQGL9ehKnwU12jGhxN+aun8itmq+nAfDR1U7K8c/2efNEj6Z9FO9zqbu3BnGdLF683D VhMQ== X-Gm-Message-State: AIkVDXJ3N0EKPeLz67Pewf+fFseE9uuvWNxKTMpQSGoJ5+6h3sXEn3LSPX6xuHCna5Grog== X-Received: by 10.55.212.28 with SMTP id l28mr3130289qki.188.1482217850319; Mon, 19 Dec 2016 23:10:50 -0800 (PST) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id q3sm12346852qte.41.2016.12.19.23.10.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Dec 2016 23:10:49 -0800 (PST) Sender: Mark Johnston Date: Mon, 19 Dec 2016 23:16:47 -0800 From: Mark Johnston To: Hiroki Sato Cc: freebsd-dtrace@freebsd.org Subject: Re: clause-local variable with copyin() Message-ID: <20161220071647.GB82223@wkstn-mjohnston.west.isilon.com> References: <20161217.151014.1579687141761225852.hrs@allbsd.org> <20161219030125.GB57753@wkstn-mjohnston.west.isilon.com> <20161220.030224.323335605995825210.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161220.030224.323335605995825210.hrs@allbsd.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 07:10:51 -0000 On Tue, Dec 20, 2016 at 03:02:24AM +0900, Hiroki Sato wrote: > Mark Johnston wrote > in <20161219030125.GB57753@wkstn-mjohnston.west.isilon.com>: > > ma> On Sat, Dec 17, 2016 at 03:10:14PM +0900, Hiroki Sato wrote: > ma> > Do I misunderstand clause-local variable? I noticed this when I use > ma> > if-then clause which was recently implemented as a syntax sugar to > ma> > split a probe automatically. The following ended up with the same > ma> > result: > ma> > ma> I think this is more a quirk of copyin() than of clause-local variables. > ma> In particular: > ma> - your example works as expected if copyinstr() is used instead of > ma> copyin(), and > ma> - your example works if one assigns this->st = stringof(copyin(...)). I meant to also note here that the example fails if a thread-local variable is used instead. > ma> > ma> copyin() and copyinstr() both copy data into a scratch buffer. However, > ma> copyinstr() returns a pass-by-reference string, while copyin() returns a > ma> pass-by-value pointer. The DIF instruction which saves to a clause-local > ma> variable, STLS, performs a deep copy of pass-by-reference variables to > ma> some dedicated storage. The scratch space containing the > ma> copyin()/copyinstr() is not preserved between enablings of the same > ma> probe, so the string copied during the first probe is not available in > ma> the second probe when copyin() is used. > > The difference of the scratch space when using copyin() and > copyinstr() were the following ("-" is copyin() and "+" is > copyinstr()): > > NAME ID KND SCP FLAG TYPE > arg0 106 scl glb r D type (integer) (size 8) > -st 500 scl loc w D type (pointer) (size 8) > +st 500 scl loc w string (unknown) by ref (size 256) > > As you explained copyinstr() had DIF_TF_BYREF and DIF_OP_STLS > performed dtrace_vcopy(). However, I still do not understand the > difference of the behavior across the boundary of two clauses for a > single probe. Is it correct that the cause is that the contents of > the scratch space which came from copyin() or copyinstr() are not > preserved across multiple clauses of a single probe? Indeed. These multiple clauses are considered to be distinct enablings of the probe, and thus get their own scratch space - see the dtrace_buffer_reserve() call near the beginning of the enabling loop in dtrace_probe(). Each enabling reserves space in the tracing buffer, but it seems that there's no mechanism to reserve space for the result of a copyin(). dtrace_ecb_action_add() computes the amount of reserved space required for each enabling of a probe and includes space for the buffer created by printf(), for example. So what happens is that STLS saves a pointer into scratch space that gets overwritten by the record header for the second enabling. I'm not claiming that this isn't a bug - perhaps copyin calls should cause space to be reserved. > If it is true, I am still wondering why copyinstr() works. I think > DIF_OP_LDLS in the second probe to load this->st always fails if the > scratch space is not preserved regardless of whether the data type > involves dereference or not. See the handling for pass-by-reference types in the STLS and LDLS implementations. STLS saves the entire string to the vstate struct in the enabling state. But variable state is shared between the enablings, so the LDLS instruction from the second probe is able to access the string.