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

Daniel Eischen deischen at
Wed May 28 15:39:23 UTC 2008

On Wed, 28 May 2008, Alexander Kabaev wrote:

> On Tue, 27 May 2008 20:04:28 +0000 (UTC)
> Xin LI <delphij at> wrote:
>> delphij     2008-05-27 20:04:27 UTC
>>   FreeBSD src repository
>>   Modified files:        (Branch: RELENG_6)
>>     include              string.h
>>     lib/libc/string 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 -0      src/include/string.h
>>    +2 -1      src/lib/libc/string/
>>    +28 -3     src/lib/libc/string/memchr.3
>>     +40 -0     src/lib/libc/string/memrchr.c (new)
>>  +1 -1      src/sys/sys/param.h
> 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
> is recorded as a requirement in binary and given
> 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.
> from RELENG_7 will  have:
> memrchr@@FBSD_1.0a
> 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

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.


More information about the cvs-src mailing list