From owner-freebsd-dtrace@freebsd.org Mon Dec 19 00:47:45 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 65A76C72D0D for ; Mon, 19 Dec 2016 00:47:45 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 2009E1DF3; Mon, 19 Dec 2016 00:47:45 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x244.google.com with SMTP id n21so177562qka.0; Sun, 18 Dec 2016 16:47:45 -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=7J54DuIYP507TqVLwVCWRhQKE45UvaqYmAJGor7/8gY=; b=RCequPwLDdJJiXd34V5LdnVlLHmV20waao1P956+FtY7aG8lgO2lt/HmGMYTqHTR8N ivDgZ6O/sPAZku7wcgs/4M2eq6lZs2jjxnhDiKQJlLkNJriPzvkNIZHJjNLyHC7+rjju u2UWK0iH/VIRkbYhSC7A5KQldilsgk2qQZgYNkR/O96fsQ3erJSUBEi5W+i2qwuLzFpr 9GgMM54/ApWjyTUms1mkbZAQtxRxQ/Qthf6fBP8Fayu0WbE4nvlhCR92bamdVQNzN5EA eNLbPXnMeCSxRV2+rNucc90ffilkJqG4VCmMjITC//unee1hlz5im06FBqbf482asrIK 1YIA== 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=7J54DuIYP507TqVLwVCWRhQKE45UvaqYmAJGor7/8gY=; b=GY3uaLrXqq6jpbGZID5NXZY0w5213o79FvxLQHd4EKII+uDM8zONnFwL8cov+COQvL ob+NydVIGs5u3ZnQD3wpqHQN8JEwYcr2Yj3sQbg4EEI+qPQlZWIXwC1luk9q0I3WrNqR fgtbL0YXcftR6GulgaqzvIai9etLWtlUWBvIGGh4Y55qXkISx9C5bng90l3ywGNoeIMD FFT+TqPuS8fQ3Nx0D1iXsMLsARjefHydhmfcARgoSIO2/pIGYxaTNKbkWrQMntXvCT0Y XqXl7CQnDr5PY2exrw7Q4ICt9fKvgRZ1U+NFblpKUbLfI/1Epy0qZP1XOHoy998pzG9M HZPQ== X-Gm-Message-State: AIkVDXJG3XafUTzL081vxtJjDbZwZzwBJJoXPiTqt54SQC+MxyY2uGu7NHTPCuVVohJG3w== X-Received: by 10.55.114.2 with SMTP id n2mr186075qkc.145.1482108464176; Sun, 18 Dec 2016 16:47:44 -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 f66sm9319741qkj.23.2016.12.18.16.47.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Dec 2016 16:47:43 -0800 (PST) Sender: Mark Johnston Date: Sun, 18 Dec 2016 16:53:42 -0800 From: Mark Johnston To: Robert Mustacchi Cc: freebsd-dtrace@freebsd.org, hrs@FreeBSD.org, swills@FreeBSD.org Subject: Re: malformed symbol Message-ID: <20161219005342.GA57753@wkstn-mjohnston.west.isilon.com> References: <20161215.075124.1459885758696268380.hrs@allbsd.org> <6b0842f5-46e8-e90e-0cc6-ec0cbe74669a@joyent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6b0842f5-46e8-e90e-0cc6-ec0cbe74669a@joyent.com> 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: Mon, 19 Dec 2016 00:47:45 -0000 On Wed, Dec 14, 2016 at 02:56:12PM -0800, Robert Mustacchi wrote: > On 12/14/16 14:51 , Hiroki Sato wrote: > > This was reproducible on 11.x and 12.x, not on 10.x. Could anyone > > try this and let me know if this is reproducible on your 11.x or 12.x > > box? I guess this is a regression of symbol rewrite routine such as > > s/__/-/ in the dtrace utility while I have not investigated the > > details yet. Or am I missing something here? > > We've seen something similar on illumos that corresponds with newer > binutils versions (2.26). See https://www.illumos.org/issues/6653. I wrote a hacky patch[1] which modifies libdtrace such that it appends the modified symbol name to the strtab instead of modifying the original name, and updates the symbol to point to the new entry. It seems to address the issue. I then wondered why we update the strtab in the first place. The code uses the modified string to look up the probe corresponding to the relocation that designates the probe site. Why can't we copy the symbol name to a buffer, call strhyphenate() on that, and use it for the lookup instead? Once the probe sites are recorded in the DOF, we shouldn't care about the symbol name. I implemented this too[2] and haven't hit any problems with some quick testing. [1] https://people.freebsd.org/~markj/patches/libdtrace_symname_swizzle.diff [2] https://people.freebsd.org/~markj/patches/libdtrace_symname_swizzle2.diff From owner-freebsd-dtrace@freebsd.org Mon Dec 19 02:55:26 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 41B53C879BB for ; Mon, 19 Dec 2016 02:55:26 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 0F54C1B1F; Mon, 19 Dec 2016 02:55:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x244.google.com with SMTP id n204so3743179qke.2; Sun, 18 Dec 2016 18:55:25 -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=CvQfomHCXg0CA7Oavb550wfCqt34mFoNJK2xl5/KDJo=; b=KntaHnX3WbYvpt4atd0owlwcTfjDEb9qYfcXTmaoZe6dOhV7vdaH4FbphJYm5ne4DK NuWy51C89X1wpzTJ9ymprHsVrLIGYvsDXYK6+e6zxuwmHj2nD0RNaBcDXMiWMKsd++fh 88dD4Xqh+tCzT73vP4Eo/EIhvwCuhCiEHOj+9/W0ly9BdtSMvvE4ZcYDTZca17vBRQVZ QZ14nxkhvfT0M9W0BYgaKPimUaYDJERRSFh4JRVZKiK0bmz56T5iJ1ko1BBfcC1aKDzG 7Y1fPmny6+V6bBAr7upzpL97s6EHmjMuFBc2czTtchTifls55n13IIAT2bYHthb5uFRt tKdA== 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=CvQfomHCXg0CA7Oavb550wfCqt34mFoNJK2xl5/KDJo=; b=AVKSCPxyzbS8OO5R10gORrBI7LyOdv3chAZWbIK+TSHzDU4i4PLqCPPAV8hP11YINQ DFQrUG6Go6v04Le0YyzoY6O26cDGwj53QSzd9MeUToIHUygeNkjH4kY4+XKfNDLRXXnA AdTKDYM7qmynUMv/m2dNzAgkEBigRGpATth4W1vPmMxH/qPYA3SeML82Ip3nEW2toNWo mPbaWp3yLBcV9ge3cngxIV8BUQzMXoy1dRoI+X9q2V0TRzJkkkyTexZlWCsCXmqH1Y5w T8ld5rtFPNoUlaxmFA/LR5cOt5jJ7zWX6Jug2jR6Un1ZTW50lQHogYnYOkMQ4wztw0IP Y+kA== X-Gm-Message-State: AIkVDXLwEylNQ1zzImDXIX+EA36Pt2VVhRg7h1ILXQ7eJg4zQ23wYmsr7/L1b3vn1hXHoQ== X-Received: by 10.55.43.158 with SMTP id r30mr1219775qkr.28.1482116125083; Sun, 18 Dec 2016 18:55:25 -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 y44sm9441124qtc.45.2016.12.18.18.55.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Dec 2016 18:55:24 -0800 (PST) Sender: Mark Johnston Date: Sun, 18 Dec 2016 19:01:25 -0800 From: Mark Johnston To: Hiroki Sato Cc: freebsd-dtrace@freebsd.org Subject: Re: clause-local variable with copyin() Message-ID: <20161219030125.GB57753@wkstn-mjohnston.west.isilon.com> References: <20161217.151014.1579687141761225852.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161217.151014.1579687141761225852.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: Mon, 19 Dec 2016 02:55:26 -0000 On Sat, Dec 17, 2016 at 03:10:14PM +0900, Hiroki Sato wrote: > Hi, > > I have trouble with clause-local variable. A minimum working example > is attached. The "sample" program simply displays a string in an > infinite loop with a USDT named as "dump-str", sample_debug.d does > copyin() and printf() the whole buffer assuming it is > nul-terminated: > > | sample$target:::dump-str > | { > | this->st = copyin(arg0, 1024); > | > | printf("(1)st = %s, %p\n", stringof(this->st), > | (char *)this->st); > | } > | sample$target:::dump-str > | { > | printf("(2)st = %s, %p\n", stringof(this->st), > | (char *)this->st); > | printf("(3)st = %s\n", stringof(copyin(arg0, 1024))); > | } > > The odd part is that it does not work with splitting the probe into > the two as above but works fine without the split. The result was as > follows: > > | % sudo make test > | dtrace -C -I/var/home/hrs/sample_str -s sample_debug.d -c /var/home/hrs/sample_str/sample > | dtrace: script 'sample_debug.d' matched 5 probes > | CPU ID FUNCTION:NAME > | 0 61714 main:dump-str (1)st = test-uname, fffffe0001a19118 > | > | 0 61714 main:dump-str (2)st = , fffffe0001a19118 > | (3)st = test-uname > > this->st became empty at the beginning of the second probe. > > The symptom varied depending on the address of this->st, so I am > guessing that this->st was incorrectly freed at the end of the first > probe. If I use copyinstr(arg0) instead of copyin(), this problem > does not occur. > > Do I misunderstand clause-local variable? I noticed this when I use > if-then clause which was recently implemented as a syntax sugar to > split a probe automatically. The following ended up with the same > result: I think this is more a quirk of copyin() than of clause-local variables. In particular: - your example works as expected if copyinstr() is used instead of copyin(), and - your example works if one assigns this->st = stringof(copyin(...)). copyin() and copyinstr() both copy data into a scratch buffer. However, copyinstr() returns a pass-by-reference string, while copyin() returns a pass-by-value pointer. The DIF instruction which saves to a clause-local variable, STLS, performs a deep copy of pass-by-reference variables to some dedicated storage. The scratch space containing the copyin()/copyinstr() is not preserved between enablings of the same probe, so the string copied during the first probe is not available in the second probe when copyin() is used. From owner-freebsd-dtrace@freebsd.org Mon Dec 19 17:35:47 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 09CAAC88E60 for ; Mon, 19 Dec 2016 17:35:47 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8215819B7 for ; Mon, 19 Dec 2016 17:35:46 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail-d.allbsd.org (p2027-ipbf1605funabasi.chiba.ocn.ne.jp [123.225.191.27]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id uBJHZJXk092753 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) (Client CN "/OU=GT07882699/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.allbsd.org", Issuer "/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3"); Tue, 20 Dec 2016 02:35:39 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.allbsd.org (alph.allbsd.org [192.168.0.10]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id uBJHY3eN045377 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Dec 2016 02:34:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.15.2/8.15.2) with ESMTPA id uBJHY123045374; Tue, 20 Dec 2016 02:34:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 19 Dec 2016 18:47:42 +0900 (JST) Message-Id: <20161219.184742.786839951753685882.hrs@allbsd.org> To: mahrens@delphix.com Cc: freebsd-dtrace@freebsd.org Subject: Re: clause-local variable with copyin() From: Hiroki Sato In-Reply-To: References: <20161217.151014.1579687141761225852.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Dec_19_18_47_42_2016_121)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [133.31.130.32]); Tue, 20 Dec 2016 02:35:41 +0900 (JST) X-Spam-Status: No, score=-98.8 required=13.0 tests=CONTENT_TYPE_PRESENT, DATE_IN_PAST_06_12, QENCPTR1, USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on gatekeeper.allbsd.org 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: Mon, 19 Dec 2016 17:35:47 -0000 ----Security_Multipart(Mon_Dec_19_18_47_42_2016_121)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew Ahrens wrote in : ma> On Fri, Dec 16, 2016 at 10:10 PM, Hiroki Sato wrote: ma> > The symptom varied depending on the address of this->st, so I am ma> > guessing that this->st was incorrectly freed at the end of the first ma> > probe. If I use copyinstr(arg0) instead of copyin(), this problem ma> > does not occur. ma> > ma> ma> Perhaps this is a bug (or at least, unexpected behavior) with copyin(). I ma> assume that it works fine with simple data types (e.g. numbers). Yes, it happens only when using copyin(). ma> I tried to test out your script on illumos but I got as far as this before ma> running out of time: ma> ma> dtrace -h -s sample_probes.d ma> gcc -c sample.c ma> dtrace -G -s sample_probes.d sample.o ma> gcc -o sample sample.o ma> dtrace -s sample_debug.d -c ./sample ma> dtrace: failed to compile script sample_debug.d: line 1: 'dump-str' is an ma> invalid probe name I confirmed that illumos-2816291 reproduced the same behavior. The sample_probes.o file should be linked to create a "sample" binary like this: % gcc -o sample sample.o sample_probes.o -- Hiroki ----Security_Multipart(Mon_Dec_19_18_47_42_2016_121)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlhXrL4ACgkQTyzT2CeTzy0MZwCgn0HV3KRK9eeJ/DPQE9I8HFH9 E+8AoML4n9WXM9TakjsabcCLwf2NS4Ba =zE8G -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Dec_19_18_47_42_2016_121)---- From owner-freebsd-dtrace@freebsd.org Mon Dec 19 18:52:15 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 01D81C88741 for ; Mon, 19 Dec 2016 18:52:15 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67B79186D; Mon, 19 Dec 2016 18:52:14 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail-d.allbsd.org (p2027-ipbf1605funabasi.chiba.ocn.ne.jp [123.225.191.27]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id uBJIpoQv062947 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) (Client CN "/OU=GT07882699/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.allbsd.org", Issuer "/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3"); Tue, 20 Dec 2016 03:52:09 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.allbsd.org (alph.allbsd.org [192.168.0.10]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id uBJIoYIl049141 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Dec 2016 03:50:34 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.15.2/8.15.2) with ESMTPA id uBJIoXIC049138; Tue, 20 Dec 2016 03:50:34 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 20 Dec 2016 03:02:24 +0900 (JST) Message-Id: <20161220.030224.323335605995825210.hrs@allbsd.org> To: markj@FreeBSD.org Cc: freebsd-dtrace@freebsd.org Subject: Re: clause-local variable with copyin() From: Hiroki Sato In-Reply-To: <20161219030125.GB57753@wkstn-mjohnston.west.isilon.com> References: <20161217.151014.1579687141761225852.hrs@allbsd.org> <20161219030125.GB57753@wkstn-mjohnston.west.isilon.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Dec_20_03_02_24_2016_631)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [133.31.130.32]); Tue, 20 Dec 2016 03:52:11 +0900 (JST) X-Spam-Status: No, score=-99.9 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on gatekeeper.allbsd.org 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: Mon, 19 Dec 2016 18:52:15 -0000 ----Security_Multipart(Tue_Dec_20_03_02_24_2016_631)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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(...)). 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? 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. -- Hiroki ----Security_Multipart(Tue_Dec_20_03_02_24_2016_631)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlhYILAACgkQTyzT2CeTzy0iMACgmAZW0gBSq1iuzq/GYqtwMGMG qWEAoI/V4657LgnTc10a/bk1sF8jxF7C =T9NS -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Dec_20_03_02_24_2016_631)---- From owner-freebsd-dtrace@freebsd.org Mon Dec 19 19:39:39 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 53B72C87527 for ; Mon, 19 Dec 2016 19:39:39 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6CCD187D; Mon, 19 Dec 2016 19:39:38 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail-d.allbsd.org (p2027-ipbf1605funabasi.chiba.ocn.ne.jp [123.225.191.27]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id uBJJdEg2006322 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) (Client CN "/OU=GT07882699/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.allbsd.org", Issuer "/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3"); Tue, 20 Dec 2016 04:39:34 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.allbsd.org (alph.allbsd.org [192.168.0.10]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id uBJJbxgR049624 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Dec 2016 04:37:59 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.15.2/8.15.2) with ESMTPA id uBJJbuSo049616; Tue, 20 Dec 2016 04:37:59 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 20 Dec 2016 04:32:29 +0900 (JST) Message-Id: <20161220.043229.1880233551388576235.hrs@allbsd.org> To: markj@FreeBSD.org Cc: rm@joyent.com, freebsd-dtrace@freebsd.org, swills@FreeBSD.org Subject: Re: malformed symbol From: Hiroki Sato In-Reply-To: <20161219005342.GA57753@wkstn-mjohnston.west.isilon.com> References: <20161215.075124.1459885758696268380.hrs@allbsd.org> <6b0842f5-46e8-e90e-0cc6-ec0cbe74669a@joyent.com> <20161219005342.GA57753@wkstn-mjohnston.west.isilon.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Dec_20_04_32_29_2016_317)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [133.31.130.32]); Tue, 20 Dec 2016 04:39:36 +0900 (JST) X-Spam-Status: No, score=-99.9 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on gatekeeper.allbsd.org 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: Mon, 19 Dec 2016 19:39:39 -0000 ----Security_Multipart(Tue_Dec_20_04_32_29_2016_317)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Johnston wrote in <20161219005342.GA57753@wkstn-mjohnston.west.isilon.com>: ma> On Wed, Dec 14, 2016 at 02:56:12PM -0800, Robert Mustacchi wrote: ma> > On 12/14/16 14:51 , Hiroki Sato wrote: ma> > > This was reproducible on 11.x and 12.x, not on 10.x. Could anyone ma> > > try this and let me know if this is reproducible on your 11.x or 12.x ma> > > box? I guess this is a regression of symbol rewrite routine such as ma> > > s/__/-/ in the dtrace utility while I have not investigated the ma> > > details yet. Or am I missing something here? ma> > ma> > We've seen something similar on illumos that corresponds with newer ma> > binutils versions (2.26). See https://www.illumos.org/issues/6653. ma> ma> I wrote a hacky patch[1] which modifies libdtrace such that it appends ma> the modified symbol name to the strtab instead of modifying the original ma> name, and updates the symbol to point to the new entry. It seems to ma> address the issue. ma> ma> I then wondered why we update the strtab in the first place. The code ma> uses the modified string to look up the probe corresponding to the ma> relocation that designates the probe site. Why can't we copy the symbol ma> name to a buffer, call strhyphenate() on that, and use it for the lookup ma> instead? Once the probe sites are recorded in the DOF, we shouldn't care ma> about the symbol name. I implemented this too[2] and haven't hit any ma> problems with some quick testing. ma> ma> [1] https://people.freebsd.org/~markj/patches/libdtrace_symname_swizzle.diff ma> [2] https://people.freebsd.org/~markj/patches/libdtrace_symname_swizzle2.diff Thank you. I tried [2] and it worked well. If it has no regression it looks better to me. -- Hiroki ----Security_Multipart(Tue_Dec_20_04_32_29_2016_317)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlhYNc0ACgkQTyzT2CeTzy2pegCgr0+Tmi5z5WNm0i7zOdyfbKRb x2QAnj+XlgoU2aSfZJKKixuLVo4et10F =yL1w -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Dec_20_04_32_29_2016_317)---- 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. From owner-freebsd-dtrace@freebsd.org Tue Dec 20 18:28:24 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 C7F04C89BC0 for ; Tue, 20 Dec 2016 18:28:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 807A01D20; Tue, 20 Dec 2016 18:28:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x243.google.com with SMTP id u25so5147441qki.2; Tue, 20 Dec 2016 10:28:24 -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=lkIt8QxcoDIWHcTKOvmY0NGoE9CSDWQPBBrjKuxcY0U=; b=FRGj+tlWwe9V5IVu2eLTx5oRJam0epddk1nEnh26RFvvx+Mfo5nCVnEKRjGrxiRiIr th/kwr6ZWy95Ax48ZJzyGJ9yfkGmlheiDkuBbcoNcDBhryx9AncXqhH1S6QJhsjJ7iCc cU4DhRB0Db1VorOC78uOu+Y8A+oIEcmx8onU/eTzSVgjHscs3CytUfoKkfzyVKqkFObN VIWUAK2P5axe5VLZj8EGzqut0TriDlHtYVJjmEpbUXvMHPX3X6kBCJgz47iG9I93qMrg 54OfDsHdoncIfV7V9Uolv3a9KJ+y/7n4hBRZP0zBHriiKX/3uGuATNZSn7wx6aiw8bK7 6O1A== 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=lkIt8QxcoDIWHcTKOvmY0NGoE9CSDWQPBBrjKuxcY0U=; b=KEq4Vm7SdGzeF0o85dsKFLRiH0W4815Nb+99tgapQio2ALMhj8tbOkILocUftcP4/3 Pq2+kcOU49VfvKMn7pG9n1as/iTjGyIJqood51SA5zpK3GFfENCivo5jtJKNxPjm085h HokPfMldWL5kblI0UTUDd4jixd8w+kYkRzINQvzR5BDRnUFEAmWHFVvOTwUQM73q4YH4 UYZioDg6yDS/D85EwcSKylQco1KM4PX6VMRz9ybbVhHRscSgGEGIEkfLd1jmU8xk2XZa Mq5fxVNiwLcv2IdF+20ZQpe8+gb5NdLoKzLEdZLiWqZM0ljUs8ULNSmmm3e+4/KEkjmO mUrg== X-Gm-Message-State: AIkVDXLXppjWOY6w08zRdweTwLV1Mes+sM+JXQPkUnvTNPrPm2hvgCjVTq2LmToq4Kf7Vw== X-Received: by 10.55.156.131 with SMTP id f125mr742776qke.177.1482258503443; Tue, 20 Dec 2016 10:28:23 -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 m30sm13568586qta.7.2016.12.20.10.28.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Dec 2016 10:28:22 -0800 (PST) Sender: Mark Johnston Date: Tue, 20 Dec 2016 10:34:16 -0800 From: Mark Johnston To: Hiroki Sato Cc: rm@joyent.com, freebsd-dtrace@freebsd.org, swills@FreeBSD.org Subject: Re: malformed symbol Message-ID: <20161220183416.GA58737@wkstn-mjohnston.west.isilon.com> References: <20161215.075124.1459885758696268380.hrs@allbsd.org> <6b0842f5-46e8-e90e-0cc6-ec0cbe74669a@joyent.com> <20161219005342.GA57753@wkstn-mjohnston.west.isilon.com> <20161220.043229.1880233551388576235.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161220.043229.1880233551388576235.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 18:28:24 -0000 On Tue, Dec 20, 2016 at 04:32:29AM +0900, Hiroki Sato wrote: > Mark Johnston wrote > in <20161219005342.GA57753@wkstn-mjohnston.west.isilon.com>: > > ma> On Wed, Dec 14, 2016 at 02:56:12PM -0800, Robert Mustacchi wrote: > ma> > On 12/14/16 14:51 , Hiroki Sato wrote: > ma> > > This was reproducible on 11.x and 12.x, not on 10.x. Could anyone > ma> > > try this and let me know if this is reproducible on your 11.x or 12.x > ma> > > box? I guess this is a regression of symbol rewrite routine such as > ma> > > s/__/-/ in the dtrace utility while I have not investigated the > ma> > > details yet. Or am I missing something here? > ma> > > ma> > We've seen something similar on illumos that corresponds with newer > ma> > binutils versions (2.26). See https://www.illumos.org/issues/6653. > ma> > ma> I wrote a hacky patch[1] which modifies libdtrace such that it appends > ma> the modified symbol name to the strtab instead of modifying the original > ma> name, and updates the symbol to point to the new entry. It seems to > ma> address the issue. > ma> > ma> I then wondered why we update the strtab in the first place. The code > ma> uses the modified string to look up the probe corresponding to the > ma> relocation that designates the probe site. Why can't we copy the symbol > ma> name to a buffer, call strhyphenate() on that, and use it for the lookup > ma> instead? Once the probe sites are recorded in the DOF, we shouldn't care > ma> about the symbol name. I implemented this too[2] and haven't hit any > ma> problems with some quick testing. > ma> > ma> [1] https://people.freebsd.org/~markj/patches/libdtrace_symname_swizzle.diff > ma> [2] https://people.freebsd.org/~markj/patches/libdtrace_symname_swizzle2.diff > > Thank you. I tried [2] and it worked well. If it has no regression > it looks better to me. Thanks! I committed a modified version of [2] as r310332.