From owner-cvs-all@FreeBSD.ORG Wed May 28 15:39:22 2008 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF55B1065675; Wed, 28 May 2008 15:39:22 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C27E18FC27; Wed, 28 May 2008 15:39:22 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m4SFdLLx027072; Wed, 28 May 2008 11:39:21 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 28 May 2008 11:39:21 -0400 (EDT) Date: Wed, 28 May 2008 11:39:21 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Alexander Kabaev In-Reply-To: <20080528091745.465f37b4@kan.dnsalias.net> Message-ID: References: <200805272004.m4RK4SZt029194@repoman.freebsd.org> <20080528091745.465f37b4@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Xin LI , cvs-all@freebsd.org Subject: Re: cvs commit: src/include string.h src/lib/libc/string Makefile.inc memchr.3 memrchr.c src/sys/sys param.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2008 15:39:23 -0000 On Wed, 28 May 2008, Alexander Kabaev wrote: > On Tue, 27 May 2008 20:04:28 +0000 (UTC) > Xin LI wrote: > >> delphij 2008-05-27 20:04:27 UTC >> >> FreeBSD src repository >> >> Modified files: (Branch: RELENG_6) >> include string.h >> lib/libc/string Makefile.inc memchr.3 >> sys/sys param.h >> Added files: (Branch: RELENG_6) >> lib/libc/string memrchr.c >> Log: >> MFC: Add memrchr(3). >> >> Obtained from: OpenBSD >> >> Revision Changes Path >> 1.21.2.2 +1 -0 src/include/string.h >> 1.34.8.2 +2 -1 src/lib/libc/string/Makefile.inc >> 1.7.14.3 +28 -3 src/lib/libc/string/memchr.3 >> 1.1.4.1 +40 -0 src/lib/libc/string/memrchr.c (new) >> http://cvsweb.FreeBSD.org/src/lib/libc/string/memrchr.c?rev=1.1.4.1&content-type=text/plain >> 1.244.2.37 +1 -1 src/sys/sys/param.h >> >> http://cvsweb.FreeBSD.org/src/include/string.h.diff?r1=1.21.2.1&r2=1.21.2.2 >> http://cvsweb.FreeBSD.org/src/lib/libc/string/Makefile.inc.diff?r1=1.34.8.1&r2=1.34.8.2 >> http://cvsweb.FreeBSD.org/src/lib/libc/string/memchr.3.diff?r1=1.7.14.2&r2=1.7.14.3 >> http://cvsweb.FreeBSD.org/src/sys/sys/param.h.diff?r1=1.244.2.36&r2=1.244.2.37 > > > There are two levels of symbol versions checking: > > 1. Up-front checking of version name. > When binary starts, rtld checks that all versions it was compiled > against are provided by the dynamically loaded libraries. I.e. if > libc.so.7:FBSD_1.1 is recorded as a requirement in binary and given > libc.so.7 does not have that version, the binary execution is > terminated right on the spot. > > The assumption here is that if version FOO is claimed to be provided by > the library then _all_ symbols@FOO binary might need are present. This > is the level of symbol versions checking Solaris provides. Linux goes a > bit further: > > 2. Per-symbol versions. > > In addition to the above, ld encodes required version of each undefined > symbol in a binary and uses (name, version) pair to resolve undefined > references as opposed to using only the symbol name. This allows for > several versions of the same symbol to exist within the binary, i.e. > something like read@FOO1 and read@FOO2 are now possible. > > Your changes broke assumption in 1. To do it 100% correctly, we probably > need to introduce a side version for memchr, something like > memrchr@@FBSD_1.0a in stable branch and provide a compatibility > alias memrchr@FBSD_1.0a for it in -current at the same time. > > libc.so.7 from RELENG_7 will have: > > memrchr@@FBSD_1.0a > > libc.so.7 from -current then will have: > > memrchr@@FBSD_1.1 > memrchr@FBSD_1.0a -> memrchr@@FBSD_1.1 Interesting, as long as "a" = ".1", so that you have FBSD_1.0.1 as the side version. See my prior email - I thought we agreed that we just MFC the version (in this case, FBSD_1.1) from -current. If you introduce a new version, a binary built on 7.x may not run on -current from before the side version was added. For instance, if we were to add memfoo() in -current now, then we release 8.0 with memfoo@@FBSD_1.1, then after the release we MFC memfoo() to RELENG_7 in the way you describe, then anything built in RELENG_7 using memfoo() will not work in 8.0 release (because 8.0 didn't have the side version memfoo@@FBSD_1.0a/1.0.1). Typically before a release there are a flurry of MFCs, so you can have a few months or more elapse before the addition of new or ABI-changed symbols. If we just use the same version as -current, then things will just work, at least from when the symbol was changed/added in -current. But regardless, I think this means that once we release 8.0, we cannot MFC any new or changed symbols (from 8.0+) back to 7.x. If someone upgrades from 7.x to 8.0, then 8.0 has to have all the symbols that 7.x will have or else binary compatibility will be broken. -- DE