[cxx-abi-dev] C++0x std::rethrow_exception, data races and the Itanium ABI

[Anthony Williams]

On 03/02/11 01:12, John McCall wrote:
> On Feb 2, 2011, at 3:35 PM, Michael Wong wrote:
>>
>> Hi, I wonder if Nathan Sidwell, Mark Michell or others can comment on
>> the feasibility of these 2 enhancement choices to enable copyable
>> exception objects.
>> A solution to this is required by C++0x LWG issue 1369 which is in
>> review status now:
>> http://lwg.github.com/issues/lwg-active.html#1369
>>
> Proposal 1 (RTTI enhancement).
>
> Adding a virtual method to RTTI objects is a non-starter.

OK.

> There's a fix to this, which is to make this a function pointer in the
> RTTI object instead.

OK.

> This proposal would require us to instantiate and emit the copy
> constructor of every class we emit RTTI for. This is actually prohibited
> by the current language spec, so we'd need language sanction for this.
> This is also a potentially significant code-size and compile-time issue.

Right. I had overlooked that.

> Proposal 2 (prepending fields to the exception data).
>
> I think this is a somewhat more elegant implementation choice,
> particularly since the original design was intended to be extended in
> this way, and it's been done before on some major platforms (in service
> of std::rethrow_exception, in fact).

That's good to know, thanks.

> We'd need a new __cxa_throw variant called something like
> __cxa_throw_copyable. I presume that throwing a trivially-copyable class
> would pass a null copy-ctor to the new variant, whereas throwing a class
> with an inaccessible or deleted copy ctor would just use __cxa_throw.
> Code throwing a non-class would still be allowed to throw with
> __cxa_throw, and std::rethrow_exception would just have to look for such
> types and DTRT.

Yes, that seems in keeping with my expectations.

> Under either proposal, the C++0x standard library would need to export
> new symbols (either the new vtables or a new __cxa_throw variant) which
> would be used by a lot of code compiled for '0x regardless of whether
> that code actually used std::rethrow_exception. This means that programs
> compiled for '0x would not be able to link against an '03 standard
> library even if they didn't actually use any '0x features requiring
> runtime support, which is actually a pretty serious concern. It's a much
> bigger problem for Proposal 1, where all code emitting RTTI for classes
> with public copy ctors would suddenly use the new symbols, whereas
> Proposal 2 would only affect code that actually contains throws.

Yes, this would be the case. However, C++03 code should still be able to 
link against the C++0x library unless there are other incompatible 
changes, so replacing the standard library with the C++0x one would work 
with all such code.

In many cases, code compiled for C++0x will also use other C++0x 
facilities that require the C++0x runtime anyway, but I accept that this 
will not necessarily be the case for existing C++03 code recompiled with 
the new compiler.

Anthony
-- 
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++0x thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976