From owner-cvs-all@FreeBSD.ORG Thu Aug 30 08:39:10 2007 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 AD15916A417; Thu, 30 Aug 2007 08:39:10 +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 5FD3D13C45A; Thu, 30 Aug 2007 08:39:10 +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.1/8.14.1/NETPLEX) with ESMTP id l7U8cv8f014530; Thu, 30 Aug 2007 04:38:57 -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-3.0 (mail.netplex.net [204.213.176.10]); Thu, 30 Aug 2007 04:38:58 -0400 (EDT) Date: Thu, 30 Aug 2007 04:38:57 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Yar Tikhiy In-Reply-To: <20070830061935.GF31948@comp.chem.msu.su> Message-ID: References: <200708270850.20904.jhb@freebsd.org> <200708281142.07941.jhb@freebsd.org> <200708281403.05931.jhb@freebsd.org> <20070829073011.GD598@comp.chem.msu.su> <20070830061935.GF31948@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, John Baldwin , alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.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: Thu, 30 Aug 2007 08:39:10 -0000 On Thu, 30 Aug 2007, Yar Tikhiy wrote: > On Wed, Aug 29, 2007 at 10:03:41AM -0400, Daniel Eischen wrote: >> On Wed, 29 Aug 2007, Yar Tikhiy wrote: >> >>> On the one hand, John's approach depends on alias symbols in HEAD >>> so, e.g., both foo@FBSD-1.9 (public) and foo@FBSD-current-1.8.5 >>> (interim) can point to the same implementation for the "foo" interface >>> after STABLE with foo@FBSD-1.9 was branched. However, the GNU build >>> tools don't seem to provide a straight way to that, they return an >>> error if multiple versions reference the same function, so more >>> stub code will be needed in the library, which will add to complexity >>> of the approach. >> >> I think you can use -z muldefs or --allow-multiple-definition as a >> linker argument to work around that. libpthread once did that (or >> something like it) so it could be compatible with libpthread.so.1 >> which used LIBPTHREAD_1_0 instead of FBSD_1_0. > > I'm afraid the ld trick won't work because the error is from as(1), > e.g.: > > : $ make > : cc -O2 -fno-strict-aliasing -pipe -c foo.c > : {standard input}: Assembler messages: > : {standard input}:4: Error: multiple versions [`foo@FBSD_1.1'|`foo@FBSD_1.0'] for symbol `foo0' > : *** Error code 1 > > : $ cat foo.c > : #include > : > : int > : foo0(int n) > : { > : return (n + 1); > : } > : > : __sym_compat(foo, foo0, FBSD_1.0); > : __sym_compat(foo, foo0, FBSD_1.1); > : > : int > : foo(int n) > : { > : return (n + 3); > : } > > Did I do anything wrong? Hmm, I guess it's not that simple. Take a look at the hack I had to make in libpthread/thread/thr_private.h (line ~67). I had to create weak references to the functions, so for your example, you'd need something like: __weak_reference(foo0, foo0_10); __weak_refefence(foo0, foo0_11); __sym_compat(foo, foo0_10, FBSD_1.0); __sym_compat(foo, foo0_11, FBSD_1.1); I think I also needed to make the latest symbol the default, changing the last line above to __sym_compat_default(foo, foo0_11, FBSD_1.1), but I seem to recall earlier email from you saying this shouldn't be needed. I _think_ I needed to for libpthread, but perhaps that is because I had the symbols (e.g. foo) listed in both sections of the map file: LIBPTHREAD_1_0 { pthread_foo; }; FBSD_1_0 { pthread_foo; }; See r.19 of libpthread/pthread.map. But this hackery isn't very pretty and is a little confusing, so perhaps that is an argument against taking this approach? Or maybe not, if you can come up with a set of macros that can be easily changed to do one thing in -current and a different thing in release brannches - you might be able to avoid changing the compat shims when branching -current to a release or MFC'ing. >>> On the other hand, Symbol.map files should not contain duplicate >>> symbol names as it seems to violate ld(1) semantics. Therefore, >>> if following Daniel's way, we'll need to track which symbols moved >>> by more than one version since the last STABLE branch to find interim >>> versions. This shouldn't be too hard, but the implementation details >>> are somewhat different. >> >> When someone changes the ABI, he's going to add a new set of symbols >> to a Symbol.map file. At this point before he commits he should >> notice that there are duplicated symbols. If he does, then he >> removes them and updates ObsoleteVersions. If he doesn't, then >> you have duplicate symbols ;-) Or you just have a script that >> does this for you (version_gen.awk might be a good starting >> point!). > > For the beginning, version_gen.awk could just complain about > duplicated symbols and suggest adding them to ObsoleteVersions as > there shouldn't be any duplicates in the whole version map generated. > Is that reasonable? BTW, what is a good place for ObsoleteVersions? > src/lib/${libname}, along with Versions.def? Or next to Symbol.map? Since duplicates might not ever occur, you would probably have an empty ObsoleteVersions file, so I'd recommend just one of them in src/lib/${libname}. Yes, I think having version_gen.awk complain and abort if it encounters duplicates might be good enough for now. Before a branch from -current, we can also manually check the libraries to make sure there are no duplicate symbols from the last branch (readelf -sW | awk ' {print $8}' | sort | some other magic). -- DE