cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h

[Yar Tikhiy]

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