On 4 October 2016 at 13:22, John McCall <[email protected]> wrote: > > On Oct 4, 2016, at 4:25 AM, David Vandevoorde <[email protected]> wrote: > > Shouldn't the ABI document specify how type_info entries are collated > and hashed with their before() and hash_code() members? > > Yes, that seems reasonable. It's only necessary for interoperation of > multiple standard libraries on a platform, but that's a thing. > > Since the ABI only formally guarantees that the names are uniqued, I think > the obviously correct way of implementing these is to compare name pointers > in before() and reinterpret the name pointer as the result of hash_code(). > That is what libc++ seems to do. I don't have a recent libstdc++ header > around; the ancient one I do have uses that rule for before() and doesn't > implement hash_code(), but IIRC these days libstdc++ uses a variant ABI for > type_info anyway. >
libstdc++ has two modes: in one mode, it guarantees typeinfo name uniqueness across the program, uses the pointer for before(), and reinterprets the pointer as a hash for hash_code. In the other mode (where they try to merge types from a .so even if it was dlopen'd RTLD_LOCAL [1]), some names are unique and others are not; hash_code computes a hash of the name, and before ... well, before is broken, and doesn't produce a strict weak order. [1]: It would seem reasonable for the ABI document to say something about what happens in this case. If I understand correctly, the issue is that a .so that's dlopen'd RTLD_LOCAL can contain a weak definition of the type_info for a type that's logically part of another library, and if it's loaded before that other library is, the type_info name doesn't get merged despite there being some intent that it's the same type. Darwin ARM64 uses a variant ABI that does not guarantee that names are > uniqued, and so we need a different rule there to handle that; in > particular, it does actually have to fall back on string comparisons and > string hashes for non-unique type info. > > John. > _______________________________________________ > cxx-abi-dev mailing list > [email protected] > http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev >
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
