luxufan wrote: > https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vague-rtti and > https://itanium-cxx-abi.github.io/cxx-abi/abi.html#typeid in the ABI require > the type name string to be globally unique, and some `std::type_info` > implementations rely on that. You might be able to do this for some specific > targets that choose a different ABI rule, but not in general.
Thanks for your reply! Yes, you are right. I checked the llvm's libcxx code, Here https://github.com/llvm/llvm-project/blob/main/libcxx/include/typeinfo#L320, it compares the equality of two types by the address of type name string. But, I have a question: now that it has ensured the uniqueness of typeinfo's address, why does the implementation still compare the type equality by the address of type name string? > Specifically: we do perform address comparisons between these strings, so the > address is significant. And we can have identical string content but > different types: > > * for types whose name involves anything with internal linkage > * for types with hidden visibility > * when loading a DSO using `RTLD_LOCAL` > > so in a few cases allowing merging could be bad. Most of that only applies > during dynamic linking. Do we have a guarantee that `unnamed_addr` is dropped > before dynamic linking? For symbols with internal linkage or hidden visibility, I don't think there would be problems if they were allowed to be merged. For example, considering there are 2 translation units 0.cpp and 1.cpp, and we defined internal `class A {}` in these 2 translation units, since they are all internal symbols, I think comparing `0.cpp::A` with `1.cpp::A` is undefined behavior. Because there at least one symbol was referenced outside of the current visibility scope. For dynamic loading, if there are two same symbols in different DSOs, does this violates the C++ one-definition-rules? https://github.com/llvm/llvm-project/pull/111343 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
