labath added a comment. In D144181#4139446 <https://reviews.llvm.org/D144181#4139446>, @Michael137 wrote:
>> Hmm, I'd sort of still be inclined to look further at the linkage name >> option - but maybe the existence of a situation where the usage is built >> with debug info, but the out of line ctor definitions are all in another >> library without debug info is a sufficiently motivating use case to justify >> the addition of these attributes to the ctor declaration. *shrug* Carry on >> then. > > That would've been convenient but I don't think we can get it right with > attaching the linkage name (even if we are willing to do the search for the > correct linkage name). That would essentially coalesce the possibly multiple > definitions of the constructor into a single one (since there's only ever a > single `CXXConstructorDecl` in the AST for a given constructor in the source) > > (CC @labath) The thing that bothers me about this approach is that finding the right constructor in the object file requires reconstructing _exactly_ the mangled name of the constructor variant, and then looking up that name in the symbol table. The construction of the mangled name does not require getting just the abi tags of the constructor itself right. Rather, it requires knowing the abi tag annotations of all arguments (template and regular) of the constructor, and template arguments of all enclosing classes. Is the information in this patch enough to reconstruct this <https://godbolt.org/z/bKqjjrv6P> name (`_ZN2S1I1AB4asdfE2S2I1BB4asdfEC2I1CB4asdfEET_1DB4asdf`, a.k.a, `S1<A[abi:asdf]>::S2<B[abi:asdf]>::S2<C[abi:asdf]>(C[abi:asdf], D[abi:asdf])`)? Even if it is, it still feels like we're not using dwarf the way it's meant to be used. Normal function would have DW_AT_linkage_name and DW_AT_addr attributes, and any one of those would be sufficient to find the function (unambiguously). The fact that we can't do that for constructors makes me believe that the problem is elsewhere. In a way, it feels like the right way to represent this situation in DWARF is to have two DW_TAG_subprogram DIEs -- given that there actually are two functions in the object file. Of course that has a lot of problems of its own -- from breaking all existing debug info consumers to figuring out how to feed this information back into clang (in the LLDB expression parser). However, since we're contemplating extensions anyway, we could at least solve the first problem fairly easily by making the extra constructor an extension -- either an extra extension DIE, or just an extra attribute (with the other linkage name) on the existing constructor. For the second part, I could imagine some kind of an extension for the `asm` annotation for constructors, which would allow one to pass two mangled names instead of one. I have no idea how hard would it be to implement it though... Anyway, that's just a dump of my thoughts on this topic. Feel free to disagree with this rant... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144181/new/ https://reviews.llvm.org/D144181 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
