[PATCH] D144181: [clang][DebugInfo] Add abi-tags on constructors/destructors as LLVM annotations

Pavel Labath via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Feb 21 04:41:00 PST 2023


labath added a comment.

In D144181#4140831 <https://reviews.llvm.org/D144181#4140831>, @Michael137 wrote:

>> 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 name (_ZN2S1I1AB4asdfE2S2I1BB4asdfEC2I1CB4asdfEET_1DB4asdf, a.k.a, S1<A[abi:asdf]>::S2<B[abi:asdf]>::S2<C[abi:asdf]>(C[abi:asdf], D[abi:asdf]))?
>
> That's a fair point. I purposefully didn't support abi_tags on all possible declarations because that would've ballooned the debug-info size too much. And we get away with it because libc++ exclusively tags functions. But of course there's no guarantee that they won't start tagging structures or namespaces

Got it.

>> 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...
>
> I've thought about doing it that way for a bit too. It does seem like a more consistent approach. What I concluded was that LLDB would have a hard time with this sort of setup. E.g., how would we know which subprogram (and thus which linkage name) to construct the single `CXXConstructorDecl` with? And once we are set on a linkage name how would we make clang pick the other one when appropriate?

Thanks for considering this.

This is what I meant by the "extension for the asm annotation for constructors" part. In principle, we could extend clang so that one can write something like this:

  class A {
    A() asm("mangled_name_for_the_full_constructor", "mangled_name_for_the_base_constructor");
  };

and then clang would automatically pick the right mangled name depending on the context. (Exact syntax TBD, and one would need to figure out what to do with "allocating ctor" and "deleting dtor" variants). Once we had that, we generate that annotation using the data we parse from the DWARF. The exact method for that would depend on the chosen format, but it shouldn't be too complicated. I suspect the hardest part would be plumb this extra info all the way through clang and llvm.

In D144181#4140924 <https://reviews.llvm.org/D144181#4140924>, @Michael137 wrote:

> Although I don't know of a scenario where we ever explicitly need to call the base object constructor from the expression evaluator.

It's definitely contrived, but I think one could write something like this:

  (lldb) expr --top-level class A : public virtual_class_from_DWARF {}
  (lldb) expr A().foo()


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144181/new/

https://reviews.llvm.org/D144181



More information about the cfe-commits mailing list