Skip to content

[llvm][DebugInfo] Drop \01 mangling prefix when inserting linkage name into accelerator table #138852

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

Merged
merged 3 commits into from
May 12, 2025

Conversation

Michael137
Copy link
Member

On some platforms (particularly macOS), a \01 prefix gets added to the name in an asm label. This gets stripped when we emit the DW_AT_linkage_name. But we weren't stripping this prefix when inserting the linkage name into accelerator tables.

This manifested in an issue where LLDB tried to look up a name in the index by linkage name, but wasn't able to find it because we indexed it with the \01 unstripped.

This patch strips the prefix before indexing.

…e into accelerator table

On some platforms (particularly macOS), a `\01` prefix gets added to the
name in an `asm` label. This gets stripped when we emit the
[`DW_AT_linkage_name`](https://github.com/llvm/llvm-project/blob/2f877c2722e882fe6aaaab44d25b7a49ba0612e1/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp#L531). But we weren't stripping this prefix when inserting the linkage name into accelerator tables.

This manifested in an issue where LLDB tried to look up a name in the
index by linkage name, but wasn't able to find it because we indexed it
with the `\01` unstripped.

This patch strips the prefix before indexing.
@llvmbot
Copy link
Member

llvmbot commented May 7, 2025

@llvm/pr-subscribers-debuginfo

Author: Michael Buch (Michael137)

Changes

On some platforms (particularly macOS), a \01 prefix gets added to the name in an asm label. This gets stripped when we emit the DW_AT_linkage_name. But we weren't stripping this prefix when inserting the linkage name into accelerator tables.

This manifested in an issue where LLDB tried to look up a name in the index by linkage name, but wasn't able to find it because we indexed it with the \01 unstripped.

This patch strips the prefix before indexing.


Full diff: https://github.com/llvm/llvm-project/pull/138852.diff

2 Files Affected:

  • (modified) llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp (+7-2)
  • (added) llvm/test/DebugInfo/Generic/debug-names-asm-label.ll (+55)
diff --git a/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp b/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
index b331854d1ee8f..010c3d6562cc1 100644
--- a/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
+++ b/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
@@ -489,12 +489,17 @@ void DwarfDebug::addSubprogramNames(
   if (SP->getName() != "")
     addAccelName(Unit, NameTableKind, SP->getName(), Die);
 
+  // We drop the mangling escape prefix when emitting the DW_AT_linkage_name. So
+  // ensure we don't include it when inserting into the accelerator tables.
+  llvm::StringRef LinkageName =
+      GlobalValue::dropLLVMManglingEscape(SP->getLinkageName());
+
   // If the linkage name is different than the name, go ahead and output that as
   // well into the name table. Only do that if we are going to actually emit
   // that name.
-  if (SP->getLinkageName() != "" && SP->getName() != SP->getLinkageName() &&
+  if (LinkageName != "" && SP->getName() != LinkageName &&
       (useAllLinkageNames() || InfoHolder.getAbstractScopeDIEs().lookup(SP)))
-    addAccelName(Unit, NameTableKind, SP->getLinkageName(), Die);
+    addAccelName(Unit, NameTableKind, LinkageName, Die);
 
   // If this is an Objective-C selector name add it to the ObjC accelerator
   // too.
diff --git a/llvm/test/DebugInfo/Generic/debug-names-asm-label.ll b/llvm/test/DebugInfo/Generic/debug-names-asm-label.ll
new file mode 100644
index 0000000000000..23c03c5c02371
--- /dev/null
+++ b/llvm/test/DebugInfo/Generic/debug-names-asm-label.ll
@@ -0,0 +1,55 @@
+; Tests the mangling escape prefix gets stripped from the linkage name.
+;
+; RUN: %llc_dwarf -accel-tables=Dwarf -dwarf-linkage-names=All -filetype=obj -o %t < %s
+;
+; RUN: llvm-dwarfdump -debug-info -debug-names %t | FileCheck %s
+; RUN: llvm-dwarfdump -debug-names -verify %t | FileCheck --check-prefix=VERIFY %s
+
+; CHECK: .debug_info contents:
+; CHECK: DW_AT_linkage_name	("bar")
+; CHECK: .debug_names contents:
+; CHECK: String: {{.*}} "bar"
+
+; There should be no verification errors for both files.
+; VERIFY: No errors.
+
+; Input generated from the following C++ code using
+; clang -g -S -emit-llvm -target aarch64-apple-macos
+
+; void foo() asm("bar");
+; void foo() {}
+; 
+; void g() { foo(); }
+
+define void @"\01bar"() !dbg !9 {
+entry:
+  ret void, !dbg !13
+}
+
+define void @_Z1gv() !dbg !14 {
+entry:
+  call void @"\01bar"(), !dbg !15
+  ret void, !dbg !16
+}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!2, !3, !4, !5, !6, !7}
+!llvm.ident = !{!8}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !1, producer: "clang version 21.0.0git", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, splitDebugInlining: false, nameTableKind: Apple, sysroot: "/")
+!1 = !DIFile(filename: "asm.cpp", directory: "/tmp", checksumkind: CSK_MD5, checksum: "d053f9249cc5548d446ceb58411ad625")
+!2 = !{i32 7, !"Dwarf Version", i32 5}
+!3 = !{i32 2, !"Debug Info Version", i32 3}
+!4 = !{i32 1, !"wchar_size", i32 4}
+!5 = !{i32 8, !"PIC Level", i32 2}
+!6 = !{i32 7, !"uwtable", i32 1}
+!7 = !{i32 7, !"frame-pointer", i32 1}
+!8 = !{!"clang version 21.0.0git"}
+!9 = distinct !DISubprogram(name: "foo", linkageName: "\01bar", scope: !10, file: !10, line: 2, type: !11, scopeLine: 2, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0)
+!10 = !DIFile(filename: "asm.cpp", directory: "/tmp", checksumkind: CSK_MD5, checksum: "d053f9249cc5548d446ceb58411ad625")
+!11 = !DISubroutineType(types: !12)
+!12 = !{null}
+!13 = !DILocation(line: 2, column: 13, scope: !9)
+!14 = distinct !DISubprogram(name: "g", linkageName: "_Z1gv", scope: !10, file: !10, line: 4, type: !11, scopeLine: 4, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0)
+!15 = !DILocation(line: 4, column: 12, scope: !14)
+!16 = !DILocation(line: 4, column: 19, scope: !14)

// If the linkage name is different than the name, go ahead and output that as
// well into the name table. Only do that if we are going to actually emit
// that name.
if (SP->getLinkageName() != "" && SP->getName() != SP->getLinkageName() &&
if (LinkageName != "" && SP->getName() != LinkageName &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Michael137 mostly asking for myself, but is there a reason we check for "" instead of empty?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope no reason in particular. This is the way the code was prior to my changes, so wanted to keep the diff as small as possible

@Michael137
Copy link
Member Author

CI error is unrelated. Seems like a flang build failure:

fatal error: file '/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-g6cdk-1/llvm-project/github-pull-requests/llvm/include/llvm/ADT/bit.h' has been modified since the precompiled header '/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-g6cdk-1/llvm-project/github-pull-requests/build/tools/flang/lib/Evaluate/CMakeFiles/FortranEvaluate.dir/cmake_pch.hxx.pch' was built: size changed (was 12409, now 12384)
note: please rebuild precompiled header '/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-g6cdk-1/llvm-project/github-pull-requests/build/tools/flang/lib/Evaluate/CMakeFiles/FortranEvaluate.dir/cmake_pch.hxx.pch'
1 error generated.

@Michael137 Michael137 merged commit cede236 into llvm:main May 12, 2025
11 checks passed
@Michael137 Michael137 deleted the llvm/mangling-escape-in-index branch May 12, 2025 12:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants