-
Notifications
You must be signed in to change notification settings - Fork 12.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[flang][debug] Generate correct name for external function. #99510
Conversation
The `ExternalNameConversion` will add an _ at the end of the external functions. We extract the real function name to use in the debug info. The convention is to use the real name of function in the `name` field and mangled name with extra _ at the end in the `linkagename` field. Fixes llvm#92391.
@llvm/pr-subscribers-flang-fir-hlfir Author: Abid Qadeer (abidh) ChangesThe Fixes #92391. Full diff: https://github.com/llvm/llvm-project/pull/99510.diff 2 Files Affected:
diff --git a/flang/lib/Optimizer/Transforms/AddDebugInfo.cpp b/flang/lib/Optimizer/Transforms/AddDebugInfo.cpp
index 8bb24fb6c8078..685a8645fa2fc 100644
--- a/flang/lib/Optimizer/Transforms/AddDebugInfo.cpp
+++ b/flang/lib/Optimizer/Transforms/AddDebugInfo.cpp
@@ -262,9 +262,13 @@ void AddDebugInfoPass::runOnOperation() {
mlir::StringAttr fullName =
mlir::StringAttr::get(context, funcOp.getName());
- auto result = fir::NameUniquer::deconstruct(funcOp.getName());
+ mlir::Attribute attr = funcOp->getAttr(fir::getInternalFuncNameAttrName());
mlir::StringAttr funcName =
- mlir::StringAttr::get(context, result.second.name);
+ (attr) ? mlir::cast<mlir::StringAttr>(attr)
+ : mlir::StringAttr::get(context, funcOp.getName());
+
+ auto result = fir::NameUniquer::deconstruct(funcName);
+ funcName = mlir::StringAttr::get(context, result.second.name);
llvm::SmallVector<mlir::LLVM::DITypeAttr> types;
fir::DebugTypeGenerator typeGen(module);
diff --git a/flang/test/Transforms/debug-92391.fir b/flang/test/Transforms/debug-92391.fir
new file mode 100644
index 0000000000000..2d83be995a0f6
--- /dev/null
+++ b/flang/test/Transforms/debug-92391.fir
@@ -0,0 +1,18 @@
+// RUN: fir-opt --add-debug-info --mlir-print-debuginfo %s | FileCheck %s
+
+module attributes {dlti.dl_spec = #dlti.dl_spec<#dlti.dl_entry<i64, dense<64> : vector<2xi64>>, #dlti.dl_entry<!llvm.ptr<272>, dense<64> : vector<4xi64>>, #dlti.dl_entry<!llvm.ptr<271>, dense<32> : vector<4xi64>>, #dlti.dl_entry<!llvm.ptr<270>, dense<32> : vector<4xi64>>, #dlti.dl_entry<f128, dense<128> : vector<2xi64>>, #dlti.dl_entry<f80, dense<128> : vector<2xi64>>, #dlti.dl_entry<i128, dense<128> : vector<2xi64>>, #dlti.dl_entry<i8, dense<8> : vector<2xi64>>, #dlti.dl_entry<!llvm.ptr, dense<64> : vector<4xi64>>, #dlti.dl_entry<i1, dense<8> : vector<2xi64>>, #dlti.dl_entry<f16, dense<16> : vector<2xi64>>, #dlti.dl_entry<f64, dense<64> : vector<2xi64>>, #dlti.dl_entry<i32, dense<32> : vector<2xi64>>, #dlti.dl_entry<i16, dense<16> : vector<2xi64>>, #dlti.dl_entry<"dlti.stack_alignment", 128 : i64>, #dlti.dl_entry<"dlti.endianness", "little">>, fir.defaultkind = "a1c4d8i4l4r4", fir.kindmap = "", llvm.data_layout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"} {
+ func.func @my_square_(%arg0: !fir.ref<i32> {fir.bindc_name = "x"} ) -> i32 attributes {fir.internal_name = "_QPmy_square"} {
+ %0 = fir.undefined !fir.dscope
+ %1 = fir.alloca i32 {bindc_name = "my_square", uniq_name = "_QFmy_squareEmy_square"}
+ %2 = fircg.ext_declare %1 {uniq_name = "_QFmy_squareEmy_square"} : (!fir.ref<i32>) -> !fir.ref<i32>
+ %3 = fircg.ext_declare %arg0 dummy_scope %0 {uniq_name = "_QFmy_squareEx"} : (!fir.ref<i32>, !fir.dscope) -> !fir.ref<i32>
+ %4 = fir.load %3 : !fir.ref<i32>
+ %5 = arith.muli %4, %4 : i32
+ fir.store %5 to %2 : !fir.ref<i32>
+ %6 = fir.load %2 : !fir.ref<i32>
+ return %6 : i32
+ } loc(#loc1)
+}
+#loc1 = loc("92391.f90":15:1)
+
+// CHECK: #di_subprogram = #llvm.di_subprogram<{{.*}}name = "my_square", linkageName = "my_square_"{{.*}}>
|
I confirmed that this fixes placing breakpoints with gdb. (lldb is still confused but given it lacks explicit fortran support, this is not surprising) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
The `ExternalNameConversion` will add an _ at the end of the external functions. We extract the real function name to use in the debug info. The convention is to use the real name of function in the `name` field and mangled name with extra _ at the end in the `linkageName` field. Fixes llvm#92391.
Summary: The `ExternalNameConversion` will add an _ at the end of the external functions. We extract the real function name to use in the debug info. The convention is to use the real name of function in the `name` field and mangled name with extra _ at the end in the `linkageName` field. Fixes #92391. Test Plan: Reviewers: Subscribers: Tasks: Tags: Differential Revision: https://phabricator.intern.facebook.com/D60251127
The
ExternalNameConversion
will add an _ at the end of the external functions. We extract the real function name to use in the debug info. The convention is to use the real name of function in thename
field and mangled name with extra _ at the end in thelinkageName
field.Fixes #92391.