rtti data structures (again)

[Nathan Sidwell]

Jason Merrill wrote:
> 
> >>>>> Nathan Sidwell <sidwell at codesourcery.com> writes:
> 
>  > I fail to see how the catch matcher can get different results comparing
>  > __tiPP1B to __tiPCPC1A as opposed to comparing __tiPP1B to __tiPCPC1B.
>  > They both look like qualification conversions of pointers to pointers to
>  > incomplete type.
> 
> Good point.  I was forgetting about multi-level qualification conversions.
> 
> I think that leaves us with something like what EDG does now: namely,
> comparisons are done by comparing the addresses of one-byte commons rather
> than of the type_info nodes themselves.  Then we could emit incomplete info
> in one file and complete info in another file and they would compare the
> same because both refer to the same ID proxy.
> 
> We could mangle the complete and incomplete versions differently, so they
> would not be combined by the linker.
This is essentially what I described in the first email I wrote about
this problem (`RTTI data layout flaw'). I'm not quite sure what you mean by
`one byte commons'. I would have thought the proxy would need a pointer to
the complete type (weak linkage of course), and a vtable. Here's what I wrote
before

> One choice which might work is some kind of __class_proxy_type_info,
> which contains a single member pointing to the real __class_type_info
> object with weak linkage. The name mangling for a
> __class_proxy_type_info will be different to that of a __class_type_info
> object. In the above case, Foo ** would be represented as
> __pointer_type_info
> ->__pointer_type_info
>   ->__class_proxy_type_info
>     ->(weakly)__class_type_info.
> The final __class_type_info object is not emitted in the compilation
> unit, as Foo's definition is never seen. Now, we can distinguish
> `Bar const *const *' from `Foo const *const *', as the inner pointers
> will point to different __class_proxy_type_info objects.

> In pointer_type_info's we do not need to go via a
> __class_proxy_type_info, if the compilation unit has seen the
> definition of the pointed-to class. The catch matching algorithm will
> need to be aware that it might be given two paths, one of which goes
> via a class_proxy_type_info, and one that does not. In this case, the
> class_proxy_type_info should point to the real class.

> type_info::operator == is not affected by proxies. Proxies are only
> important when traversing the pointer heirarchy in catch matching.

Is that what you had in mind? Martin wondered why we needed the proxy,
wouldn't an __incomplete_type_info node be sufficient? But I think that
would fail across multiple object files. I.e. fileA and fileB have
`struct A' as incomplete and fileC has `struct A' as complete. The linker
has to know that the objects named __ti1A in fileA and fileB must be
discarded in favour of that in fileC, should all three be linked together.
If only fileA and fileB are linked, then the two must be commonized. I
don't think ELF can deal with that, can it?

There's a bit of strangeness with loading & unloading a DSO which contains
the complete definition of `struct A', into an executable which has the
incomplete info. That too is in the original email. If both DSO and
executable have __tiP1A (struct A *), they'll be merged, presumably
with the DSO's copy ignored. However, the __tiP1A in the executable
will point at the proxy incomplete A type_info (which will have already
been filled with a weak NULL for its target). Somehow we have to arrange
that the proxy is altered to now point at the __ti1A (struct A) type_info
that the DSO supplied. If we don't do that, throwing `struct A *' in the
DSO (which is valid, `cos the DSO source had complete information), will
throw the __tiP1A in the executable which points to incomplete. Hence
we wont find any base conversions if we're trying to catch a base of A.

I hope you see what I mean here -- I don't know enough about DSO loading
details to know what'll happen.

[I'll get to your other points when I've some more time, thanks]

nathan
-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
Never hand someone a gun unless you are sure where they will point it
nathan at acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan at cs.bris.ac.uk