From owner-freebsd-arch@FreeBSD.ORG Tue Jul 21 19:18:54 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B16E91065674 for ; Tue, 21 Jul 2009 19:18:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4BAE28FC17 for ; Tue, 21 Jul 2009 19:18:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n6LJ3Cpq028196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 22:03:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n6LJ3CXq069886; Tue, 21 Jul 2009 22:03:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n6LJ3COV069885; Tue, 21 Jul 2009 22:03:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 21 Jul 2009 22:03:12 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20090721190312.GH55190@deviant.kiev.zoral.com.ua> References: <200907191725.n6JHPOBe049379@svn.freebsd.org> <200907200951.56551.jhb@freebsd.org> <4e571dd70907210800m451681fdhedb951e4351d8233@mail.gmail.com> <200907211134.23565.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RNDwH1ysJEL7MpMz" Content-Disposition: inline In-Reply-To: <200907211134.23565.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: arch@freebsd.org, Gordon Tetlow Subject: Re: svn commit: r195767 - in head: . cddl/lib cddl/lib/libctf cddl/lib/libdtrace gnu/lib/libdialog gnu/lib/libg2c gnu/lib/libobjc gnu/lib/libreadline gnu/lib/libregex lib lib/libalias/libalias lib/liba... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 19:18:55 -0000 --RNDwH1ysJEL7MpMz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 21, 2009 at 11:34:23AM -0400, John Baldwin wrote: > On Tuesday 21 July 2009 11:00:27 am Gordon Tetlow wrote: > > On Mon, Jul 20, 2009 at 6:51 AM, John Baldwin wrote: > >=20 > > > I guess specifically I see a disconnect in that in our current policy= we > > > trust > > > developers to know when a change is an ABI change for a library with > > > versioned symbols, but we don't trust them to know when a change is a= n ABI > > > change for a library without versioned symbols. Either we trust=20 > developers > > > to recognize an ABI change or not. Whether or not the library has > > > versioned > > > symbols doesn't change that, and the resulting mess if we get it wron= g is > > > just as ugly in either case. > >=20 > >=20 > > Is there a way to detect ABI changes automatically? Is there some tool= that > > could be written to detect changes in ABI and throw warnings about in t= hat > > case? >=20 > I am not aware of one, and I think it would be hard to detect things like > changes in structure layout (e.g. you can have an ABI change w/o changing > the size if you just reorder fields). Even a tool that could check for a > subset of breakages would still be useful. We need the checker that can parse ELF and dwarf2, and produces the printouts of the all exported functions with corresponding versions, and structure definitions in some canonical forms, not neccessary in C syntax. Such code is architecture-depended, that is good. As an added benefit, it will be possible to show the padding. Next, we either diff the printouts, or teach the tools to report on any added/missed symbols, changed function signatures or structure layouts. We do have libelf and libdwarf in the base, that could be considered as the "lexer" foundation of the tool. The tool is quite doable, but requires a time. This is definitely not a weekend project, in my opinion. --RNDwH1ysJEL7MpMz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpmEO8ACgkQC3+MBN1Mb4h4IgCcCbl2OohPRNkVPwbhtd85aCqQ S1EAnjfjAl3w1NLl2wB2b8ikHCadMD6o =0v/e -----END PGP SIGNATURE----- --RNDwH1ysJEL7MpMz--