Meeting results 12 October

[Nathan Sidwell]

Jim Dehnert wrote:

> ----------------
> RTTI portability
> ----------------

> A program that is built from pieces from different compilers, where the
> pieces come from different implementations of the hierarchy, will see
> different structures, at least in the vtables, if we allow this extra
> material to be arbitrary, creating a problem if such programs actually
> make use of parts of the hierarchy.
What is being meant by `used' here? It is only the vtables that will be
different, and then the implementation parts will be in the later
parts of the vtable. Thus accessing the std defined entry points will
work across compilers. Do you mean
A) a user program derives from abi::pointer_type_info and then attempts
to use objects of that class within the type_info system?
B) parts of the program other than those in libcxa.so attempt to use
the implentation defined entry points?

I think A is user error and B is only possible with Martin's example below.

>   First, observe that the vtables for the typeinfo derived classes will
>   be emitted where the key function (the virtual destructor, as
>   defined) is defined.  We require this to be in the implementation's
>   runtime library libcxa.so, so there is exactly one implementation of
>   them on any given target system.
One of Martin's concerns was about creating a library FOO with
`ld -Bsymbolic' against one compiler's libcxa.so, and then ultimately
using that library in an executable with a different compiler's libcxa.so.
FOO will contain copies of the first compiler's implementation of the
type_info vtables and implementation functions. If we are to permit
such a library, we have to guarantee that there are no implementation
defined parts of the vtable _or_ type_info instances.

>   We allow the implementation to define a collection of pseudo-virtual
>   functions to be associated with each class derived from std::type_info:
...
>   Construction of one of the std::type_info derivatives can either call
>   the constructor or use the mangled name to initialize the __aux
>   member.
> 
>   Use of __aux is reserved to the runtime implementation.
How does this help? Given Martin's -Bsymbolic example we'd just get
different versions of __cxa_aux_type_info in FOO and the runtime. The
same problem would still be manifest.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan at codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan at acm.org