From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Taahir Ahmed Newsgroups: gmane.lisp.guile.devel Subject: Exception-safety for C++ code integrated with Guile. Date: Mon, 23 Feb 2015 15:59:43 -0600 Message-ID: <474913203.jcqxqasMgP@basis> Reply-To: ahmed.taahir@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart67847836.aNjt8AT0zC"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1424728816 10039 80.91.229.3 (23 Feb 2015 22:00:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Feb 2015 22:00:16 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Feb 23 23:00:07 2015 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YQ12o-0005Oo-FB for guile-devel@m.gmane.org; Mon, 23 Feb 2015 23:00:02 +0100 Original-Received: from localhost ([::1]:45603 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQ12o-0005Pg-2I for guile-devel@m.gmane.org; Mon, 23 Feb 2015 17:00:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59876) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQ12g-0005LI-J0 for guile-devel@gnu.org; Mon, 23 Feb 2015 16:59:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQ12b-0005Og-DV for guile-devel@gnu.org; Mon, 23 Feb 2015 16:59:54 -0500 Original-Received: from mail-ob0-x232.google.com ([2607:f8b0:4003:c01::232]:34371) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQ12b-0005OR-7X for guile-devel@gnu.org; Mon, 23 Feb 2015 16:59:49 -0500 Original-Received: by mail-ob0-f178.google.com with SMTP id uz6so39447484obc.9 for ; Mon, 23 Feb 2015 13:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:reply-to:subject:date:message-id:user-agent:mime-version :content-type; bh=gv7nUySRVsOewj6oPnsfjen3T82G7xPawaQeXUWwzRw=; b=D/Mgkz3IZqDTELwLWkRyXXGd8uCQjcshSz6m3Tp7IyiwB2fVi+la5K2TczHW3RryvX j5R/1Yycm3oQ0zPStAOOCVm0+dLoyv1Ogw9ak7w2wNtPjy1FrcVDwf7LUrIs7rU+BKiD DTQc4C4ON8PhWrjIt+5PjW/3iG5StqcCMDWywC4pD9ODZuZRRJixlrvEOn7j13487S7W zkca3z3zo60Go4Hf25HxLyS7abpBSbj0+WdMX5Uy4WrjTavXUMWHCC0wWiHsLIEzbThQ go/iRTDo8WXATpw3PuLSeQojOPkz7QZLQgYkPZzLLd9JXml7MPNd/P1g+jPRLn1FCqlp lJSQ== X-Received: by 10.182.121.162 with SMTP id ll2mr6247443obb.71.1424728788668; Mon, 23 Feb 2015 13:59:48 -0800 (PST) Original-Received: from basis.localnet (nat-165-91-12-5.tamulink.tamu.edu. [165.91.12.5]) by mx.google.com with ESMTPSA id r83sm22264219oif.28.2015.02.23.13.59.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 13:59:48 -0800 (PST) User-Agent: KMail/4.14.3 (Linux/3.16.5-gentoo; KDE/4.14.3; x86_64; ; ) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::232 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17672 Archived-At: --nextPart67847836.aNjt8AT0zC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Over the past few days, I've been working on reducing the amount of defensive coding that is required when writing Guile extensions using C++. My primary goal is to ensure that destructors of automatic variables are called if any Guile non-local control flow passes through a C++ stack frame. I'm writing to the list for three purposes: 1) To check that I'm not duplicating any other ongoing work, 2) To float two different implementation strategies and see which one is the best choice going forward, and 3) To get clarification on some issues that I've encountered with a prototype implementation. The two major strategies I considered are: 1) Replace all uses of set/longjmp in the Guile source with C++ exceptions. This approach is simple in some ways, and complicated in others. I would hesitate to pursue this unless Guile has some sort of longer-term plan to move towards C++. 2) Replace all uses of set/longjmp with replacements (call them eh_setjmp and eh_longjmp) that are based on libunwind [1]. eh_longjmp uses libunwind to walk up the stack, calling each frame's personality routine [2]. This approach will requires a platform that uses DWARF exception handling (i.e., everybody except non-Cygwin Windows). It has the potential to make calls to setjmp much faster, but calls to longjmp would take linear (as opposed to constant) time in the number of stack frames crossed. I've started working on a proof-of-concept for option 2 (heavily cribbed from libunwind's own set/longjmp replacement). However, I've run into an issue --- many of Guile's uses of setjmp don't conform to the C standard. In particular, after experiencing a non-local return from setjmp, you're not allowed to access any non-volatile local variables, but Guile does (see the local variable mx in eval()). In effect, Guile is assuming that setjmp saves and restores registers, but the standard doesn't require that behavior from setjmp. I can make my setjmp implementation save all registers, but I decided to first check and see if this was a conscious decision to embrace nonportability, or an accidental one. Thanks, Taahir Ahmed =2D--------------------------------------------------------------------- [1] http://www.nongnu.org/libunwind/index.html [2] http://mentorembedded.github.io/cxx-abi/abi-eh.html#base-personalit= y --nextPart67847836.aNjt8AT0zC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJU66LTAAoJEP0dGB2mOaLGKK4H/A3zM38oyQKqwdIWd6u+CZ8u 5+OW/1wDfmtTrX7q8EPAsj4xKEHDmQ0bPBE7uwbM0QqKrXxhw1nA1I7fCHg+VTzF Gn2jF3vBzMfF/EcfmBCSIXRZa3Rwt8QmmCaaYb2dV+6zhUoWhv00xocfxXVWOZij NAsJJsYeM0+6qo/Y+lXiLSUnMCzSVdZuKEZ7J93LyHcJFLNVKc+xZ/B/yvLcPbNd NgfLn3BAZXpeFbtP9J5YtneE3MC5s3C21MOf5lLfRLdqog6jJYeFzPd2Mfw5CNMZ 7GWhI75BHgWB1Gp4Kc1b/5Q2TkrF0z54xvBYgM5bCTv1Nxmi1PoyHw8ZId5ho6s= =i1Y2 -----END PGP SIGNATURE----- --nextPart67847836.aNjt8AT0zC--