svn commit: r261801 - head/contrib/libc++/include

[Alexander Kabaev]

On Thu, 13 Feb 2014 10:11:27 +0000
David Chisnall <theraven at FreeBSD.org> wrote:

> On 13 Feb 2014, at 01:04, Alexander Kabaev <kabaev at gmail.com> wrote:
> 
> > The refusal to use tools that are there precisely to help to help
> > with the binary compatibility in favor of mindless library bumps is
> > just sad.
> 
> Perhaps you could share with the class.  What is the correct way of
> solving this problem?  
> 
> For those just joining the discussion, the issue is that std::pair
> was originally declared with an explicit constructor and should have
> an implicit constructor, which has a different calling convention.
> This means that we can't share the two std::pair implementations
> across libraries, because they will try to call the constructor with
> the wrong arguments.  Because of templates and C++ name mangling,
> this ends up being propagated into most libraries that link against
> libc++, and calling from one with the old definition to one with the
> new definition end up causing segfaults (if we're lucky - I think the
> symptom that we're seeing is actually dereferencing a junk value in a
> register, so it may cause random memory writes, but I'd have to check
> the ABI).  
> 
> Given that neither redeclaring the new std::pair in a new namespace,
> nor exporting both constructor symbols using symbol versioning (the
> two approaches that we've already discussed) will work, what are the
> tools that apparently we're refusing to use that will work?
> 
> David

OK, I think the confusion has started because reported to this as an ABI
incompatibility within libc++ itself, which is not the case here.

When calling convention of a public symbol changes, one can put the old
definition under the compatibility version that is only available for
runtime binding, this allowing old binaries to work and that is what I
was referring to. Unfortunately, that won't work in this case because
libc++ proper does NOT export any symbols with 'pair' in them, so it is
not affected by the ABI breakage itself. What libc++ developers did is
they exported ABI breakage into every binary that was compiled with
different revisions on libc++ _header_ files, not linked with the
library proper. Using the library major version as a circumstantial
evidence indicating header versions binary was compiled with might work
then, though is not 100% reliable. Theoretically one can compile the
binary that uses std::pair template but does not record libc++ as the
runtime dependency. Still, that is better than nothing.

ABI stability and C++ apparently should be mentioned in the same
sentence, unless there's also a 'pipe dream' in it. And you do deserve
an apology for my remark. 

-- 
Alexander Kabaev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140213/44b878cc/attachment.sig>