Skip to content

[DebugInfo] Implement TAG_label entries for debug_names #71724

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 1 commit into from
Nov 13, 2023

Conversation

felipepiovezan
Copy link
Contributor

The DWARF 5 specification says that:

The name index must contain an entry for each debugging information entry that
defines a named [...] label [...].

The verifier currently verifies this, but the AsmPrinter does not add entries for TAG_labels in debug_names. This patch addresses the issue by ensuring we add labels in the accelerator tables once we have a fully completed DIE for the TAG_label entry.

We also respect the spec as follows:

DW_TAG_label debugging information entries without an address attribute
(DW_AT_low_pc, DW_AT_high_pc, DW_AT_ranges, or DW_AT_entry_pc) are excluded.

The effect of this on the size of accelerator tables is minimal, as TAG_labels are usually created by C/C++ labels (see example in test), which are typically paired with "goto" statements.

The DWARF 5 specification says that:

> The name index must contain an entry for each debugging information entry that
> defines a named [...] label [...].

The verifier currently verifies this, but the AsmPrinter does not add entries
for TAG_labels in debug_names. This patch addresses the issue by ensuring we add
labels in the accelerator tables once we have a fully completed DIE for the
TAG_label entry.

We also respect the spec as follows:
> DW_TAG_label debugging information entries without an address attribute
> (DW_AT_low_pc, DW_AT_high_pc, DW_AT_ranges, or DW_AT_entry_pc) are excluded.

The effect of this on the size of accelerator tables is minimal, as TAG_labels
are usually created by C/C++ labels (see example in test), which are typically
paired with "goto" statements.
@llvmbot
Copy link
Member

llvmbot commented Nov 8, 2023

@llvm/pr-subscribers-debuginfo

Author: Felipe de Azevedo Piovezan (felipepiovezan)

Changes

The DWARF 5 specification says that:

> The name index must contain an entry for each debugging information entry that
> defines a named [...] label [...].

The verifier currently verifies this, but the AsmPrinter does not add entries for TAG_labels in debug_names. This patch addresses the issue by ensuring we add labels in the accelerator tables once we have a fully completed DIE for the TAG_label entry.

We also respect the spec as follows:
> DW_TAG_label debugging information entries without an address attribute
> (DW_AT_low_pc, DW_AT_high_pc, DW_AT_ranges, or DW_AT_entry_pc) are excluded.

The effect of this on the size of accelerator tables is minimal, as TAG_labels are usually created by C/C++ labels (see example in test), which are typically paired with "goto" statements.


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

2 Files Affected:

  • (modified) llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp (+12-3)
  • (modified) llvm/test/DebugInfo/X86/debug-names-dwarf64.ll (+55-2)
diff --git a/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp b/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
index 42bf755737506b4..feb5ab665a17d8c 100644
--- a/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
+++ b/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
@@ -1422,9 +1422,18 @@ void DwarfCompileUnit::finishEntityDefinition(const DbgEntity *Entity) {
       llvm_unreachable("DbgEntity must be DbgVariable or DbgLabel.");
   }
 
-  if (Label)
-    if (const auto *Sym = Label->getSymbol())
-      addLabelAddress(*Die, dwarf::DW_AT_low_pc, Sym);
+  if (!Label)
+    return;
+
+  const auto *Sym = Label->getSymbol();
+  if (!Sym)
+    return;
+
+  addLabelAddress(*Die, dwarf::DW_AT_low_pc, Sym);
+
+  // A TAG_label with a name and an AT_low_pc must be placed in debug_names.
+  if (StringRef Name = Label->getName(); !Name.empty())
+    getDwarfDebug().addAccelName(*CUNode, Name, *Die);
 }
 
 DbgEntity *DwarfCompileUnit::getExistingAbstractEntity(const DINode *Node) {
diff --git a/llvm/test/DebugInfo/X86/debug-names-dwarf64.ll b/llvm/test/DebugInfo/X86/debug-names-dwarf64.ll
index 8cd1f0c18292093..e5fd6be033ca767 100644
--- a/llvm/test/DebugInfo/X86/debug-names-dwarf64.ll
+++ b/llvm/test/DebugInfo/X86/debug-names-dwarf64.ll
@@ -10,6 +10,10 @@
 ; CHECK-NEXT:                   DW_AT_name ("foo")
 ; CHECK:      [[TYPEDIE:.+]]: DW_TAG_base_type
 ; CHECK-NEXT:                   DW_AT_name ("int")
+; CHECK:      [[SPDIE:.+]]:   DW_TAG_subprogram
+; CHECK:                        DW_AT_name ("func")
+; CHECK:      [[LABELDIE:.+]]: DW_TAG_label
+; CHECK-NEXT:                   DW_AT_name ("MyLabel")
 
 ; CHECK:      .debug_names contents:
 ; CHECK-NEXT: Name Index @ 0x0 {
@@ -19,8 +23,8 @@
 ; CHECK-NEXT:     CU count: 1
 ; CHECK-NEXT:     Local TU count: 0
 ; CHECK-NEXT:     Foreign TU count: 0
-; CHECK-NEXT:     Bucket count: 2
-; CHECK-NEXT:     Name count: 2
+; CHECK-NEXT:     Bucket count: 4
+; CHECK-NEXT:     Name count: 4
 ; CHECK:        }
 ; CHECK-NEXT:   Compilation Unit offsets [
 ; CHECK-NEXT:     CU[0]: 0x00000000
@@ -30,6 +34,14 @@
 ; CHECK-NEXT:       Tag: DW_TAG_variable
 ; CHECK-NEXT:       DW_IDX_die_offset: DW_FORM_ref4
 ; CHECK-NEXT:     }
+; CHECK-NEXT:     Abbreviation [[ABBREV_SP:0x[0-9a-f]*]] {
+; CHECK-NEXT:       Tag: DW_TAG_subprogram
+; CHECK-NEXT:       DW_IDX_die_offset: DW_FORM_ref4
+; CHECK-NEXT:     }
+; CHECK-NEXT:     Abbreviation [[ABBREV_LABEL:0x[0-9a-f]*]] {
+; CHECK-NEXT:       Tag: DW_TAG_label
+; CHECK-NEXT:       DW_IDX_die_offset: DW_FORM_ref4
+; CHECK-NEXT:     }
 ; CHECK-NEXT:     Abbreviation [[ABBREV:0x[0-9a-f]*]] {
 ; CHECK-NEXT:       Tag: DW_TAG_base_type
 ; CHECK-NEXT:       DW_IDX_die_offset: DW_FORM_ref4
@@ -56,6 +68,29 @@
 ; CHECK-NEXT:         DW_IDX_die_offset: [[VARDIE]]
 ; CHECK-NEXT:       }
 ; CHECK-NEXT:     }
+; CHECK-NEXT:     Name 3 {
+; CHECK-NEXT:       Hash: 0x7C96FE71
+; CHECK-NEXT:       String: {{.+}} "func"
+; CHECK-NEXT:       Entry @ {{.+}} {
+; CHECK-NEXT:         Abbrev: [[ABBREV_SP]]
+; CHECK-NEXT:         Tag: DW_TAG_subprogram
+; CHECK-NEXT:         DW_IDX_die_offset: [[SPDIE]]
+; CHECK-NEXT:       }
+; CHECK-NEXT:     }
+; CHECK-NEXT:   ]
+; CHECK-NEXT:   Bucket 2 [
+; CHECK-NEXT:     EMPTY
+; CHECK-NEXT:   ]
+; CHECK-NEXT:   Bucket 3 [
+; CHECK-NEXT:     Name 4 {
+; CHECK-NEXT:       Hash: 0xEC64E52B
+; CHECK-NEXT:       String: {{.+}} "MyLabel"
+; CHECK-NEXT:       Entry @ {{.+}} {
+; CHECK-NEXT:         Abbrev: [[ABBREV_LABEL]]
+; CHECK-NEXT:         Tag: DW_TAG_label
+; CHECK-NEXT:         DW_IDX_die_offset: [[LABELDIE]]
+; CHECK-NEXT:       }
+; CHECK-NEXT:     }
 ; CHECK-NEXT:   ]
 ; CHECK-NEXT: }
 
@@ -64,12 +99,25 @@
 ; IR generated and reduced from:
 ; $ cat foo.c
 ; int foo;
+; void func() {
+;   goto MyLabel;
+;
+; MyLabel:
+;   return 1;
+; }
 ; $ clang -g -gpubnames -S -emit-llvm foo.c -o foo.ll
 
 target triple = "x86_64-unknown-linux-gnu"
 
 @foo = dso_local global i32 0, align 4, !dbg !0
 
+define void @func() !dbg !11 {
+  call void @llvm.dbg.label(metadata !15), !dbg !14
+  ret void, !dbg !14
+}
+
+declare void @llvm.dbg.label(metadata)
+
 !llvm.dbg.cu = !{!2}
 !llvm.module.flags = !{!7, !8, !9}
 !llvm.ident = !{!10}
@@ -85,3 +133,8 @@ target triple = "x86_64-unknown-linux-gnu"
 !8 = !{i32 2, !"Debug Info Version", i32 3}
 !9 = !{i32 1, !"wchar_size", i32 4}
 !10 = !{!"clang version 12.0.0"}
+!11 = distinct !DISubprogram(name: "func", linkageName: "func", scope: !3, file: !3, line: 2, type: !12,  unit: !2)
+!12 = !DISubroutineType(types: !13)
+!13 = !{null}
+!14 = !DILocation(line: 2, column: 13, scope: !11)
+!15 = !DILabel(scope: !11, name: "MyLabel", file: !3, line: 5)

Copy link
Member

@JDevlieghere JDevlieghere left a comment

Choose a reason for hiding this comment

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

LGTM

@felipepiovezan
Copy link
Contributor Author

I will go ahead and merge this, since it seems fairly straightforward.

@felipepiovezan felipepiovezan merged commit a195d1f into llvm:main Nov 13, 2023
@felipepiovezan felipepiovezan deleted the felipe/tag_label_in_accel branch November 13, 2023 19:03
felipepiovezan added a commit to felipepiovezan/llvm-project that referenced this pull request Nov 13, 2023
The DWARF 5 specification says that:

> The name index must contain an entry for each debugging information
entry that
> defines a named [...] label [...].

The verifier currently verifies this, but the AsmPrinter does not add
entries for TAG_labels in debug_names. This patch addresses the issue by
ensuring we add labels in the accelerator tables once we have a fully
completed DIE for the TAG_label entry.

We also respect the spec as follows:
> DW_TAG_label debugging information entries without an address
attribute
> (DW_AT_low_pc, DW_AT_high_pc, DW_AT_ranges, or DW_AT_entry_pc) are
excluded.

The effect of this on the size of accelerator tables is minimal, as
TAG_labels are usually created by C/C++ labels (see example in test),
which are typically paired with "goto" statements.

(cherry picked from commit a195d1f)
zahiraam pushed a commit to zahiraam/llvm-project that referenced this pull request Nov 20, 2023
The DWARF 5 specification says that:

> The name index must contain an entry for each debugging information
entry that
> defines a named [...] label [...].

The verifier currently verifies this, but the AsmPrinter does not add
entries for TAG_labels in debug_names. This patch addresses the issue by
ensuring we add labels in the accelerator tables once we have a fully
completed DIE for the TAG_label entry.

We also respect the spec as follows:
> DW_TAG_label debugging information entries without an address
attribute
> (DW_AT_low_pc, DW_AT_high_pc, DW_AT_ranges, or DW_AT_entry_pc) are
excluded.

The effect of this on the size of accelerator tables is minimal, as
TAG_labels are usually created by C/C++ labels (see example in test),
which are typically paired with "goto" statements.
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