zygoloid wrote: > 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?
The uniqueness of the address of the `type_info` object itself is not guaranteed. The reason is that we sometimes [generate `type_info` objects for pointers to incomplete types](https://itanium-cxx-abi.github.io/cxx-abi/abi.html#:~:text=When%20it%20is,the%20type_info%20addresses.) as part of exception handling, so we can end up with multiple `type_info` objects for the same type. > 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. Such comparisons can happen in valid C++ code. For example: ```c++ // a.cc namespace { class A {}; } void throwA() { throw A(); } ``` ```c++ // b.cc namespace { class A {}; } void throwA(); int main() { try { throwA(); } catch (A) { return 1; } catch (...) { return 2; } } ``` This program is valid and `main` is required to return 2 -- the `A` in `a.cc` and the `A` in `b.cc` are two different types. During exception handling, we will compare them by comparing their `type_info`, which means we will compare the addresses of the name strings, so we need two different addresses. > For dynamic loading, if there are two same symbols in different DSOs, the > symbol would be interposed. Not in the cases I mentioned. (I think we can *probably* get away with marking type name strings as `unnamed_addr` if the type has external linkage, because we don't expect `unnamed_addr` to have any effect after static linking. But it's not clear to me that that's actually guaranteed by the LLVM semantics, or whether it would be permissible to make use of `unnamed_addr` in some cross-DSO LTO situation.) You *can* still apply `unnamed_addr` in the cases where the the target ABI rule is that `type_info` comparisons will always use or fall back to a string comparison. Per the libc++ implementation, that's that case on Apple arm64 targets. You can detect this using `classifyRTTIUniqueness`. I think it's also correct and safe to apply `local_unnamed_addr` to these type name strings in all cases. Merging with another string literal from the same compilation should always be OK. 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
