From owner-svn-src-all@FreeBSD.ORG Thu Feb 13 15:29:31 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF482555; Thu, 13 Feb 2014 15:29:31 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 246F21FE0; Thu, 13 Feb 2014 15:29:31 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id m5so2986361qaj.4 for ; Thu, 13 Feb 2014 07:29:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; bh=t6eytiBDv2hymf7hjZYnttRf2lXdgcC3zCObu/j1v48=; b=1IIhQ5ontxpsv656mxYPk+9joi9AewKGVav+45CT4u2tA6/aOInqbbnftVYlGmfVNo LRNpsI+tMZJHifkjxYR0R7gNLga17wUln7yhD5GZZoI3iiYJKXIsIUCRQKDeGaGq+guo DqMfrOhmqQ2n3U/NjAg3qvogGsW2OvK1ShprzlSlmccXoZROIAaO3E1gVgpZmArzAg3t T9R32t/r43MhQrqFffSsij5tODyGucOZW7RWVSL4cL4inineui73BCsKIa4TSKehou7S JMfx/ujzjhQvsKTWdiLohj/9gUZoD02AZuKk7dVwffSUYV7WN8Rntg1Fl7Q3OHemj8gp Ihsw== X-Received: by 10.140.47.101 with SMTP id l92mr3338635qga.9.1392305370168; Thu, 13 Feb 2014 07:29:30 -0800 (PST) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPSA id i38sm3024020qge.1.2014.02.13.07.29.28 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 13 Feb 2014 07:29:29 -0800 (PST) Date: Thu, 13 Feb 2014 10:29:22 -0500 From: Alexander Kabaev To: David Chisnall Subject: Re: svn commit: r261801 - head/contrib/libc++/include Message-ID: <20140213102922.240cbcb0@kan.dyndns.org> In-Reply-To: <75044DC7-D682-44A0-A384-E7B0C4D942DC@FreeBSD.org> References: <201402121814.s1CIEo5A016765@svn.freebsd.org> <52FBC08C.30309@FreeBSD.org> <52FBC570.6080003@FreeBSD.org> <20140212200413.71c6db5b@kan.dyndns.org> <75044DC7-D682-44A0-A384-E7B0C4D942DC@FreeBSD.org> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/kYQpGtjrlkV5=ty9S6UDFvW"; protocol="application/pgp-signature" Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Dimitry Andric , Jung-uk Kim X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:29:31 -0000 --Sig_/kYQpGtjrlkV5=ty9S6UDFvW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 13 Feb 2014 10:11:27 +0000 David Chisnall wrote: > On 13 Feb 2014, at 01:04, Alexander Kabaev wrote: >=20 > > The refusal to use tools that are there precisely to help to help > > with the binary compatibility in favor of mindless library bumps is > > just sad. >=20 > Perhaps you could share with the class. What is the correct way of > solving this problem? =20 >=20 > For those just joining the discussion, the issue is that std::pair > was originally declared with an explicit constructor and should have > an implicit constructor, which has a different calling convention. > This means that we can't share the two std::pair implementations > across libraries, because they will try to call the constructor with > the wrong arguments. Because of templates and C++ name mangling, > this ends up being propagated into most libraries that link against > libc++, and calling from one with the old definition to one with the > new definition end up causing segfaults (if we're lucky - I think the > symptom that we're seeing is actually dereferencing a junk value in a > register, so it may cause random memory writes, but I'd have to check > the ABI). =20 >=20 > Given that neither redeclaring the new std::pair in a new namespace, > nor exporting both constructor symbols using symbol versioning (the > two approaches that we've already discussed) will work, what are the > tools that apparently we're refusing to use that will work? >=20 > David OK, I think the confusion has started because reported to this as an ABI incompatibility within libc++ itself, which is not the case here. When calling convention of a public symbol changes, one can put the old definition under the compatibility version that is only available for runtime binding, this allowing old binaries to work and that is what I was referring to. Unfortunately, that won't work in this case because libc++ proper does NOT export any symbols with 'pair' in them, so it is not affected by the ABI breakage itself. What libc++ developers did is they exported ABI breakage into every binary that was compiled with different revisions on libc++ _header_ files, not linked with the library proper. Using the library major version as a circumstantial evidence indicating header versions binary was compiled with might work then, though is not 100% reliable. Theoretically one can compile the binary that uses std::pair template but does not record libc++ as the runtime dependency. Still, that is better than nothing. ABI stability and C++ apparently should be mentioned in the same sentence, unless there's also a 'pipe dream' in it. And you do deserve an apology for my remark.=20 --=20 Alexander Kabaev --Sig_/kYQpGtjrlkV5=ty9S6UDFvW Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iD8DBQFS/OTXQ6z1jMm+XZYRAoW2AKDc/lS0wcFkKHoW3MP3KSX+0u0EUQCglpN9 t8+VXjZKKlsirllH/I24JkY= =T+Om -----END PGP SIGNATURE----- --Sig_/kYQpGtjrlkV5=ty9S6UDFvW--