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)----