cvs commit: src/include string.h src/lib/libc/string Makefile.inc memchr.3 memrchr.c src/sys/sys param.h

[Daniel Eischen]

On Wed, 28 May 2008, Alexander Kabaev wrote:

> On Tue, 27 May 2008 20:04:28 +0000 (UTC)
> Xin LI <delphij at FreeBSD.org> 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 at 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 at FOO1 and read at 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 at 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 at 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