ojhunt wrote: > > > > > I didn't thought the linkage of vtable is related to targets. > > > > > > On Mach-O, a weak vtable that is unnamed_addr lowers to a > > > > > > .weak_def_can_be_hidden definition > > > > > > > > > > > > > > > Is this only possible on Mach-O? I mean, if this is an optimization, > > > > > why didn't it work on other platforms? > > > > > > > > > > > > It may be a matter of other platforms not having got around to it, or > > > > platform constraints make it less viable/valuable? It probably benefits > > > > platforms where mapped system libraries can be aggressively shared > > > > across many processes, but I'm not a linker person if I can help it. > > > > > > > > > I still don't understand why this is platform specific... Or what is the > > > bad side of the behavior? > > > > > > I think there will be issues where it depends on the stdlib handling RTTI > > with duplicate type definitions - so probably this is something that each > > platform needs to decide on > > The OP said: > > "On Mach-O, a weak vtable that is unnamed_addr lowers to a > .weak_def_can_be_hidden definition, which the static linker coalesces and > then drops from the dynamic export trie. Keeping these vtables out of the > exported symbol set cuts the work dyld has to do at load time." > > I think weak symbols can always duplicated on all platforms. And whether or > not a symbol can be duplicated shouldn't be related to stdlib as far as I > know.
The reason vtables have weak symbols is because they _can't_ be duplicated (according to the standard), the weak symbols are to support unification. I guess stdlib is the wrong term - it's the actual runtime implementing RTTI in a way that supports multiple definitions of the same type (e.g. the typename string compare fall back). There's also an element of: we know the rules for our platform's runtimes and linker, because this technically implies ODR violations, making the decision blindly for other platforms seems questionable. https://github.com/llvm/llvm-project/pull/205930 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
