May libc++ support symbol versioning?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

May libc++ support symbol versioning?

suyash singh via cfe-dev
Hi,

I got message from FreeBSD about whether
they can upgrade to V2 ABI.  To summarize
the discussion:

  FreeBSD is not willing to land an ABI
  break unless it is for the purpose of
  introducing symbol version because
  breaking libc++ ABI means breaking
  ABI in three actively supported
  FreeBSD versions.  There is no such
  thing called "break in the next release."

May libc++ support symbol versioning
in V2 or a specific variant of ABI?

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________



_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: May libc++ support symbol versioning?

suyash singh via cfe-dev
On Tue, Feb 25, 2020 at 06:30:21AM +0000, Zhihao Yuan via cfe-dev wrote:

> Hi,
>
> I got message from FreeBSD about whether
> they can upgrade to V2 ABI.  To summarize
> the discussion:
>
>   FreeBSD is not willing to land an ABI
>   break unless it is for the purpose of
>   introducing symbol version because
>   breaking libc++ ABI means breaking
>   ABI in three actively supported
>   FreeBSD versions.  There is no such
>   thing called "break in the next release."
>
> May libc++ support symbol versioning
> in V2 or a specific variant of ABI?

As I wrote in that thread, symbol versioning doesn't fix any of the
problems ABI stability in libc++ has.

Joerg
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: May libc++ support symbol versioning?

suyash singh via cfe-dev
In reply to this post by suyash singh via cfe-dev
Hi,

I would be interested to know who is making that statement on behalf of
the FreeBSD project.  We made a conscious decision *not* to use symbol
versioning for the FreeBSD build of libc++ when we imported it.

Symbol versioning allows you to provide versions for exported symbols.
This is a good solution for maintaining backwards compatibility in C
libraries, where the only things exported from a library are functions
(or, occasionally, globals) and it is often possible to provide
backwards-compatibility versions of functions.  For example, FreeBSD
libc provides some compat versions of stat for callers that will provide
a smaller statbuf structure than the newer version of the API expects to
fill.

In contrast, C++ libraries export complex types and expect to inline a
large number of the operations on them.  The boundary of a C++ library
is much more fuzzy.  Types declared in libc++ headers become part of the
name mangling for any functions that take them as arguments.  Symbol
versioning does not help with that at all.

Libc++ does provide a mechanism for incrementally changing the ABI.  All
of the standard types are declared in the std::__v1 namespace.  We could
provide the new versions in the std::__v2 namespace and conditionally
import either version into the std namespace depending on the
compilation options.  That would allow code linked against libc++ today
to continue to use the old versions, but allow new code to adopt the new
versions, with the caveat that it would change name mangling of any
function that took a standard library type as arguments, so you would
not be able to mix a library built with old libc++ with one built
against new libc++.

This solution is not actually much better than FreeBSD bumping the
SONAME and relegating the old libc++ to a COMPAT version.  I was under
the impression that this was the plan for FreeBSD 12, but apparently it
didn't happen.  It is something that should definitely be done for
FreeBSD 13.

David

On 25/02/2020 06:30, Zhihao Yuan via cfe-dev wrote:

> Hi,
>
> I got message from FreeBSD about whether
> they can upgrade to V2 ABI.  To summarize
> the discussion:
>
>    FreeBSD is not willing to land an ABI
>    break unless it is for the purpose of
>    introducing symbol version because
>    breaking libc++ ABI means breaking
>    ABI in three actively supported
>    FreeBSD versions.  There is no such
>    thing called "break in the next release."
>
> May libc++ support symbol versioning
> in V2 or a specific variant of ABI?
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
>
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: May libc++ support symbol versioning?

suyash singh via cfe-dev
In reply to this post by suyash singh via cfe-dev


> On Feb 25, 2020, at 01:30, Zhihao Yuan <[hidden email]> wrote:
>
> Hi,
>
> I got message from FreeBSD about whether
> they can upgrade to V2 ABI.  To summarize
> the discussion:

Just pointing out that ABI v2 is not a thing in libc++. We have ABI v1, and we have the unstable ABI. We haven't stabilized any v2 yet, and it's not clear how/when/whether this will happen.

Louis

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: May libc++ support symbol versioning?

suyash singh via cfe-dev
On Feb 25, 2020, 11:39 AM, Louis Dionne < [hidden email]> wrote:
> Just pointing out that ABI v2 is not a thing in libc++. We have ABI v1, and we have the unstable ABI. We haven't stabilized any v2 yet, and it's not clear how/when/whether this will happen.

I know. I asked if unstable ABI is frozen, may FreeBSD upgrade.

--
Zhihao

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: May libc++ support symbol versioning?

suyash singh via cfe-dev
In reply to this post by suyash singh via cfe-dev
On Tuesday, February 25, 2020 8:49 AM, David Chisnall via cfe-dev <[hidden email]> wrote:

> Hi,
>
> I would be interested to know who is making that statement on behalf of
> the FreeBSD project. We made a conscious decision not to use symbol
> versioning for the FreeBSD build of libc++ when we imported it.

The thread is here; you are welcome to check it out:

https://lists.freebsd.org/pipermail/freebsd-hackers/2020-February/055669.html

>
> Symbol versioning allows you to provide versions for exported symbols.
> This is a good solution for maintaining backwards compatibility in C
> libraries, where the only things exported from a library are functions
> (or, occasionally, globals) and it is often possible to provide
> backwards-compatibility versions of functions. For example, FreeBSD
> libc provides some compat versions of stat for callers that will provide
> a smaller statbuf structure than the newer version of the API expects to
> fill.
>
> In contrast, C++ libraries export complex types and expect to inline a
> large number of the operations on them. The boundary of a C++ library
> is much more fuzzy.

Apparently, libstdc++ did it.

> Types declared in libc++ headers become part of the
> name mangling for any functions that take them as arguments. Symbol
> versioning does not help with that at all.

libc++ had never changed name
mangling regarding types, IIUC.

--
Zhihao
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: May libc++ support symbol versioning?

suyash singh via cfe-dev
On 26/02/2020 16:28, Zhihao Yuan wrote:
>> I would be interested to know who is making that statement on behalf of
>> the FreeBSD project. We made a conscious decision not to use symbol
>> versioning for the FreeBSD build of libc++ when we imported it.
> The thread is here; you are welcome to check it out:
>
> https://lists.freebsd.org/pipermail/freebsd-hackers/2020-February/055669.html

FWIW: Joerg is exactly correct in that thread.  Symbol versioning does
not solve the problem, for precisely the reasons that he outlines.  C++
inline namespaces provide a strictly richer set of functionality than
ELF symbol versioning and libc++ uses them for ABI stability.  This does
not help libraries that pass libc++ types across library boundaries.

For example, consider library A defines a function:

void printString(std::string);

Library B calls this function.

Library A is compiled with the current version of libc++.  This function
is mangled as:

_Z11printStringNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE

Which translates to:

printString(std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >)

Now we release a new version of libc++ which provides a new ABI-breaking
std::string representation and use the __2 inline namespace.  Both can
coexist in the same libc++ binary.

Library A moves to a new version of libc++ and recompiles against the
new headers.  Now the same function becomes the mangled equivalent of:

printString(std::__2::basic_string<char, std::__1::char_traits<char>,
std::__2::allocator<char> >)

(Assuming that char_traits and allocator remain the same).  Now library
B will get link failures.

Now, it would be possible for library A to explicitly provide a compat
version of the printString function by providing a function like this:

void printString(std::__2::string);

In C++, if both provide an adequate API, it would even be possible to
move the implementation into a template that is instantiated in two
overloads of printString, one with std::__1::string and the other with
std::string.

Unfortunately, that's the trivial case.  Any classes declared in headers
exposed by library A will also need compat versions.

Given that most libraries will not go to this trouble, the end result is
effectively a flag day.  That is not so bad for FreeBSD, where the
entire package set is built together.  It would be possible to ship a
version of libc++ that included both the __1 and __2 symbols but
defaulted to the __2 versions, then rebuild the ports collection (which
happens at least once a week anyway) against the __2 version once all of
the older versions of the base system have reached EOL.

David
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: May libc++ support symbol versioning?

suyash singh via cfe-dev
On Wednesday, February 26, 2020 11:16 AM, David Chisnall <[hidden email]> wrote:

> > https://lists.freebsd.org/pipermail/freebsd-hackers/2020-February/055669.html
>
> FWIW: Joerg is exactly correct in that thread. Symbol versioning does
> not solve the problem, for precisely the reasons that he outlines. C++
> inline namespaces provide a strictly richer set of functionality than
> ELF symbol versioning and libc++ uses them for ABI stability. This does
> not help libraries that pass libc++ types across library boundaries.
>
> void printString(std::__2::string);
>

Not the case with -D_LIBCPP_ABI_UNSTABLE

So the question is what should libc++
deliver to FreeBSD in its first
unavoidable break, because I suppose,
nobody in FreeBSD want to break all
three stable versions again after this.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev