[clang][DebugInfo] Emit DW_AT_object_pointer on function definitions with explicit this
#122897
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…with explicit `this` We currently don't emit `DW_AT_object_pointer` on function declarations or definitions. The DWARFv5 spec doesn't mandate this attribute be present *only* for implicit object parameters: ``` If the member function entry describes a non-static member function, then that entry has a DW_AT_object_pointer attribute whose value is a reference to the formal parameter entry that corresponds to the object for which the function is called. That parameter also has a DW_AT_artificial attribute whose value is true. ``` The part about `DW_AT_artificial` seems overly restrictive, and not true for explicit object parameters. We probably should relax this part of the DWARF spec. This will help LLDB identify static vs. non-static member functions (see llvm#120856). GCC suffers from the same issue: https://godbolt.org/z/h4jeT54G5 Partially fixes llvm#120974
llvmbot
added
clang
|
@llvm/pr-subscribers-debuginfo @llvm/pr-subscribers-clang Author: Michael Buch (Michael137) ChangesWe currently don't emit If I interpreted the DWARFv5 spec correctly, it doesn't mandate this attribute be present only for implicit object parameters: This patch attaches the The part about This will help LLDB identify static vs. non-static member functions (see #120856). Partially fixes #120974 Full diff: https://github.com/llvm/llvm-project/pull/122897.diff 2 Files Affected:
diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp b/clang/lib/CodeGen/CGDebugInfo.cpp
index d7e5e95b7873a0..f9cba414dcfe2c 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -4829,6 +4829,9 @@ llvm::DILocalVariable *CGDebugInfo::EmitDeclare(const VarDecl *VD,
if (IPD->getParameterKind() == ImplicitParamKind::CXXThis ||
IPD->getParameterKind() == ImplicitParamKind::ObjCSelf)
Flags |= llvm::DINode::FlagObjectPointer;
+ } else if (const auto *PVD = dyn_cast<ParmVarDecl>(VD)) {
+ if (PVD->isExplicitObjectParameter())
+ Flags |= llvm::DINode::FlagObjectPointer;
}
// Note: Older versions of clang used to emit byval references with an extra
diff --git a/clang/test/CodeGenCXX/debug-info-object-pointer.cpp b/clang/test/CodeGenCXX/debug-info-object-pointer.cpp
new file mode 100644
index 00000000000000..594d4da791ee84
--- /dev/null
+++ b/clang/test/CodeGenCXX/debug-info-object-pointer.cpp
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -x c++ -std=c++23 -debug-info-kind=limited -emit-llvm < %s | FileCheck %s
+
+// CHECK: !DISubprogram(name: "bar",
+// CHECK-SAME: flags: DIFlagPrototyped
+// CHECK: !DIDerivedType(tag: DW_TAG_pointer_type
+// CHECK-SAME: flags: DIFlagArtificial | DIFlagObjectPointer
+//
+// // FIXME: DIFlagObjectPointer not attached to the explicit object
+// // argument in the subprogram declaration.
+// CHECK: !DISubprogram(name: "explicit_this",
+// flags: DIFlagPrototyped
+// CHECK-NOT: DIFlagObjectPointer
+// CHECK-NOT: DIFlagArtificial
+//
+// CHECK: !DILocalVariable(name: "this", arg: 1
+// CHECK-SAME: flags: DIFlagArtificial | DIFlagObjectPointer
+//
+// CHECK-NOT: DIFlagArtificial
+// CHECK: !DILocalVariable(arg: 1, {{.*}}, flags: DIFlagObjectPointer)
+
+struct Foo {
+ void bar() {}
+ void explicit_this(this Foo &&) {}
+};
+
+void f() {
+ Foo{}.bar();
+ Foo{}.explicit_this();
+}
|
|
@dwblaikie @adrian-prantl any thoughts on adjusting the DWARF spec to allow explicit |
I would suggest posting an issue to dwarf-discuss that just turns that into and give an example. Also maybe of a language like Python where self is quite explicit. |
adrian-prantl
approved these changes
Jan 14, 2025
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/30/builds/13812 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/38/builds/1830 Here is the relevant piece of the build log for the reference |
github-actions bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Jan 17, 2025
…eclarations with explicit `this` (#122928) In llvm/llvm-project#122897 we started attaching `DW_AT_object_pointer` to function definitions. This patch does the same but for function declarations (which we do for implicit object pointers already). Fixes llvm/llvm-project#120974
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We currently don't emit
DW_AT_object_pointeron function declarations or definitions. GCC suffers from the same issue: https://godbolt.org/z/h4jeT54G5Fixing this will help LLDB in identifying static vs. non-static member functions (see #120856).
If I interpreted the DWARFv5 spec correctly, it doesn't mandate this attribute be present only for implicit object parameters:
This patch attaches the
DW_AT_object_pointerfor function defintions. The declarations will be handled in a separate patch.The part about
DW_AT_artificialseems overly restrictive, and not true for explicit object parameters. We probably should relax this part of the DWARF spec.Partially fixes #120974