svn commit: r299090 - in head: etc/mtree include lib/libbluetooth sbin/hastd share/man/man3 sys/dev/xen/blkback sys/kern sys/net sys/sys tests/sys tests/sys/sys usr.sbin/bluetooth/hccontrol

[John Baldwin]

On Thursday, May 05, 2016 10:45:21 AM Alan Somers wrote:
> On Thu, May 5, 2016 at 10:31 AM, John Baldwin <jhb at freebsd.org> wrote:
> 
> > On Wednesday, May 04, 2016 10:34:11 PM Alan Somers wrote:
> > > Author: asomers
> > > Date: Wed May  4 22:34:11 2016
> > > New Revision: 299090
> > > URL: https://svnweb.freebsd.org/changeset/base/299090
> > >
> > > Log:
> > >   Improve performance and functionality of the bitstring(3) api
> > >
> > >   Two new functions are provided, bit_ffs_at() and bit_ffc_at(), which
> > allow
> > >   for efficient searching of set or cleared bits starting from any bit
> > offset
> > >   within the bit string.
> > >
> > >   Performance is improved by operating on longs instead of bytes and
> > using
> > >   ffsl() for searches within a long. ffsl() is a compiler builtin in both
> > >   clang and gcc for most architectures, converting what was a brute force
> > >   while loop search into a couple of instructions.
> > >
> > >   All of the bitstring(3) API continues to be contained in the header
> > file.
> > >   Some of the functions are large enough that perhaps they should be
> > uninlined
> > >   and moved to a library, but that is beyond the scope of this commit.
> >
> > Doesn't switching from bytes to longs break the ABI?  That is, setting bit
> > 9
> > now has a different representation on big-endian systems (0x00 0x01 before,
> > now 0x00 0x00 0x01 0x00 on 32-bit BE, and 4 more leading 0 bytes on
> > 64-bit).
> > This means you can't have an object file compiled against the old header
> > pass a bitstring to an object file compiled against the new header on
> > big-endian
> > systems.
> >
> > Even on little-endian systems if an old object file allocates storage for a
> > bitstring the new code might read off the end of it and fault (or return
> > garbage if bits are set in the extra bytes it reads off the end)?
> >
> > Is the API is so little used we don't care?
> >
> > --
> > John Baldwin
> >
> 
> The API isn't used in any shared libraries, so the only risk would be if
> it's used in a user application where the user's build system doesn't check
> for changes in system libraries, and the user upgrades FreeBSD without
> doing a clean build of his application, right?  Am I missing any other
> scenarios?  Do we need to warn users with a line in UPDATING or something?

It would matter more if it was used in any 3rd party applications (e.g. in
/usr/ports), though it needs to cross an API boundary to matter.  I can believe
that bitstring(3) is obscure enough that nothing uses it, but the ABI needs to
be considered.  We can't ever change cpuset_t from longs to uint32_t's for
example (which is what sigset_t uses) because it is used in various system
calls (e.g. consider using cpuset(8) in an old jail).

> This is similar to an upgrade of the C++ compiler.  C++ objects built by
> different minor versions of the compiler aren't guaranteed to be compatible.

Erm, that's definitely not true.  Changes to libstdc++ or libc++ might
generate incompatible objects, and there has been a lot of anguish in the past
when GCC has done that (see how it had to revert changes to std::list in
libstdc++ that were done to make it C++11 compliant but broke the ABI of
std::list).  You can even mix objects from GCC and clang and it will work fine
(e.g. use clang or newer versions of GCC to build user applications that link
against libraries in the base system built with a different version of either
gcc or clang).

-- 
John Baldwin