On Sat, Jan 26, 2013 at 10:23:58AM +0000, David Chisnall wrote: > On 25 Jan 2013, at 19:59, Konstantin Belousov wrote: > > > I am really tired of the constant struggle against the consumation of > > the FreeBSD as the test-bed for the pre-alpha quality software. E.g., > > are we fine with broken C++ runtime in 9 ? > > Please can you stop the FUD here? It really isn't helpful. We have a > working C++ runtime in 9.1: libcxxrt. In fact, we have a working C++11 > stack in 9.1, with the combination of libcxxrt, libc++, and clang++. > Unfortunately, the filter library configuration for libsupc++ left > some symbols in the wrong symbol version (the ABI library version > instead of the STL library version) and so there are some issues in > corner cases[1], which I am working on fixing. I have a fix for the > most common corner cases, but I want to make sure that I have caught > all of them before I commit. This will happen tomorrow. > > The filter library is very important to have working for 10.0, because > we will need the ports and compat versions of libstdc++ to use it if > we want to be able to mix code that uses libstdc++ (i.e. any ports > that don't work correctly with libc++) and libc++ (i.e. any ports that > use C++11, which is going to be an increasing number over the next few > years). > > David > > [1] In particular, terminate handlers are not correctly set, and > exceptions thrown from the runtime library are not of the expected > type. This means that C++ code that calls std::set_terminate() will > not work and neither will code that calls __cxa_bad_alloc() and > friends and then tries to catch the resulting exception. The only code > I have seen that actually does this is a test case that I wrote for > libcxxrt. In general, code encountering either of these problems is > already in a very broken state and the only difference you will see is > a less helpful error message before it crashes.
I do not see how the code demonstrated as failing in standards/175453 could be classified as 'broken' or 'so special that nobody does it'. It is perfectly valid, and my reaction for such breakage is that C++ runtime is completely broken. How pointing to this fact can be FUD ? Your initial assesment of the problem as a misbehaviour of the combination of filtering and versioning made no sense to me, I asked you to provide the isolated test case, which you did not. Our implementation of filters indeed only allows for the filtered symbol to have the same version as the filtee symbol. I re-read the SUN documentation about filters (who had designed them), and looked at what Linux does there. It seems to me that Sun document spirit forces us to behave in a way which our rtld currently does. Linux behaviour is useless there, IMHO, since their rtld just inserts filtee before filter in the global lookup order (I may be wrong there). I do suggest (again) that the way to fix the issue is to provide the isolated test-case and decide if the behaviour of rtld is right. If we conclude that the problem is not in rtld but in the versioning mismatch between libraries (libstdc++ and libsupc++), I again suggest to provide the patch for review first. The ABI seems to become too unwieldly, and making ad-hoc changes there could paint us into the corner.
pgpu2cXQjxZaw.pgp
Description: PGP signature
