rtti data structures (again)

[Jason Merrill]

>>>>> Nathan Sidwell <sidwell at codesourcery.com> writes:

 >> 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.

It would work either way: I was talking about an identity proxy that the
type_infos point to; you were talking about an incomplete type proxy that
points to the real type_info for the type.  Your proposal might be
smaller.

 > 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?

No, I agree.

 > 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 do see what you mean.  I don't think that the EDG scheme I was talking
about would have a problem with this situation.

Jason