From owner-cvs-all@FreeBSD.ORG Tue Sep 4 11:14:08 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 C40CA16A419; Tue, 4 Sep 2007 11:14:08 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 0C88513C468; Tue, 4 Sep 2007 11:14:07 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l84BE1JZ087557; Tue, 4 Sep 2007 15:14:01 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l84BE1b1087552; Tue, 4 Sep 2007 15:14:01 +0400 (MSD) (envelope-from yar) Date: Tue, 4 Sep 2007 15:14:00 +0400 From: Yar Tikhiy To: Daniel Eischen Message-ID: <20070904111400.GM30502@comp.chem.msu.su> 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 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: cvs-src@freebsd.org, cvs-all@freebsd.org, src-committers@freebsd.org, "M. Warner Losh" , John Baldwin 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 List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 11:14:09 -0000 On Thu, Aug 30, 2007 at 04:38:57AM -0400, Daniel Eischen wrote: > > 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. Just tried this trick, and, alas, it didn't really help. Namely it helped to make the library buildable, but not all alias versions of the symbol ended up in it. I tested various combinations of the __weak_reference, __sym_compat, and __sym_default directives in conjunction with different symbol maps listing the symbol under one or many versions. The result was the same: only one alias version was in the library and available to apps linked against it, while the other was absent. > 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. With my experience with it in mind, I'm afraid this hackery is in the dark grey area of the linker, so we'd better avoid it altogether. > >>>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). I tried to implement that in version_gen.awk and found that its error handling was rather weak. Therefore I also improved its error handling and fixed a few other bugs. Could you please review my changes? They are in p4 and rev#1 corresponds to the version from the CVS repo: http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/user/yar/hack/share/mk/version%5fgen.awk And, I think now we can outline the plan for using SV in the fts(3) ABI change. 0. Goals: To provide CURRENT users with smooth experience before the next major release, when their tests and feedback are very important. To test drive our symbol versioning implementation and the newborn policy for its use. NOT to work around bugs in the build system -- they're being worked on under a different task guided by our make(1) guru Ruslan Ermilov. 1. Commit: - The new versions of symbols are listed under FBSD_1.1 in the respective Symbol.map file. - The old versions are kept under FBSD_1.0 using __sym_compat() directives, and they are listed in src/lib/libc/ObsoleteVersions. 2. Release: In RELENG_7, the old versions are eliminated, which includes the following: - disconnecting the old implementation from the build in src/lib/libc/gen/Makefile.inc; - deleting the old implementation in CVS: src/lib/libc/gen/fts-compat.*; - removing references to the old symbols from ObsoleteVersions. 3. HEAD cleanup: Half a year later the same removal procedure is applied to HEAD. Did I miss anything? Oh, and we haven't decided on the format of ObsoleteVersions yet. What about using just the same symbol map format for it? Thanks! -- Yar