[DebugInfo] Generate debug information for labels.

[HsiangKai]

Summary

Generate DILabel metadata and call llvm.dbg.label after label statement to associate the metadata with the label. This patch should be reviewed with D45024.

[chenwj]

Nits.

lib/CodeGen/CGDebugInfo.cpp

3644

Indent.

lib/CodeGen/CGStmt.cpp

535

I assume you emit debug info for the label only if it's reachable by checking HaveInsertPoint(). If so, make the comment as

// Emit debug info for the label only if it's reachable.

I prefer adding braces here. Please check indent as well.

[HsiangKai]

1. No generating llvm.dbg.label intrinsic.
2. Modify commits according to chenwj's comments.

[HsiangKai]

Update the test case for inlined functions. The inlined label will attach to DISubprogram(..., labels: !n)

[aprantl]

One question, but otherwise this looks fine.

lib/CodeGen/CGStmt.cpp

535

Shouldn't it be added to the list of labels/variables of the DISubprogram regardless?

[HsiangKai]

Update test cases.

[HsiangKai]

Always add labels to DISubprogram even unreachable.

[JDevlieghere]

Please run your changes through clang format before checking this in; otherwise LGTM.

[HsiangKai]

• Update test cases.
• Checked with clang-format.

[HsiangKai]

@chenwj Do you have any comments for this patch?

[hans]

This broke the Chromium build. I've uploaded a reproducer at https://bugs.chromium.org/p/chromium/issues/detail?id=841170#c1

I'm guessing maybe a Clang bootstrap with debug info might also reproduce the problem, but I haven't tried that.

Reverted in r331861.

[HsiangKai]

In D45045#1092697, @hans wrote:

This broke the Chromium build. I've uploaded a reproducer at https://bugs.chromium.org/p/chromium/issues/detail?id=841170#c1

I'm guessing maybe a Clang bootstrap with debug info might also reproduce the problem, but I haven't tried that.

Reverted in r331861.

https://reviews.llvm.org/D46738 should fix the bug.

[HsiangKai]

In D45045#1114280, @HsiangKai wrote:

In D45045#1092697, @hans wrote:

This broke the Chromium build. I've uploaded a reproducer at https://bugs.chromium.org/p/chromium/issues/detail?id=841170#c1

I'm guessing maybe a Clang bootstrap with debug info might also reproduce the problem, but I haven't tried that.

Reverted in r331861.

https://reviews.llvm.org/D46738 should fix the bug.

rL336176 has fixed the bug. Could I revert the commit?
You could refer to PR37395.

[hans]

In D45045#1150525, @HsiangKai wrote:

In D45045#1114280, @HsiangKai wrote:

In D45045#1092697, @hans wrote:

This broke the Chromium build. I've uploaded a reproducer at https://bugs.chromium.org/p/chromium/issues/detail?id=841170#c1

I'm guessing maybe a Clang bootstrap with debug info might also reproduce the problem, but I haven't tried that.

Reverted in r331861.

https://reviews.llvm.org/D46738 should fix the bug.

rL336176 has fixed the bug. Could I revert the commit?
You could refer to PR37395.

I'm not familiar with your patch, but if you're confident that it works (for example, a clang bootstrap works), then committing again sounds good to me.

[vext01]

Looks like this was backed out (reverted) yesterday.

I'm really interested in inserting DILabels from LLVM in my research project, so I hope it can be recovered.

[HsiangKai]

In D45045#1184313, @vext01 wrote:

Looks like this was backed out (reverted) yesterday.

I'm really interested in inserting DILabels from LLVM in my research project, so I hope it can be recovered.

You could apply it locally. In most cases, it works fine.

Currently, I still work on some problems when you use label in goto expression and you do some calculation on it under optimization.
Following is the test case I try to resolve the problem.

int tab[9];

void execute(unsigned short *oip, unsigned short *ip)
{
  int x = 0;
  int *xp = tab;
base:
  x++;
  if (x == 4)
    {
      *xp = 0;
      return;
    }
  *xp++ = ip - oip;
  goto *(&&base + *ip++);
}

int main()
{
  unsigned short ip[10];
  int i;
  for (i = 0; i < 10; i++)
    ip[i] = 0;
  execute(ip, ip);

  return 0;
}

If you do not use label in such complex way, I think you could apply it temporarily.

[vext01]

Hi HsiangKai,

Thanks for the response.

Indeed, I've just rolled back to just before the revert for now to experiment, but I do hope this change hits LLVM-7.

Wishing you the best of luck with getting it merged!

[vext01]

Hi,

I've been experimenting some more with this patch.

It seems to me that if a label is optimised away, but you've requested it be preserved, then you get a DWARF label with a zero offset. Is that the expected behaviour? Should it be documented?

E.g.:

< 6><0x000000dc>              DW_TAG_label
                                DW_AT_name                  __YK_BLK_2_19418_0
                                DW_AT_low_pc                0x00000000

Thanks!

[HsiangKai]

In D45045#1189201, @vext01 wrote:

Hi,

I've been experimenting some more with this patch.

It seems to me that if a label is optimised away, but you've requested it be preserved, then you get a DWARF label with a zero offset. Is that the expected behaviour? Should it be documented?

E.g.:

< 6><0x000000dc>              DW_TAG_label
                                DW_AT_name                  __YK_BLK_2_19418_0
                                DW_AT_low_pc                0x00000000

Thanks!

I expect that even the code is optimized out, the label will point to somewhere in the function. If the whole function is optimized out, the label should not exist any more. It should not have address zero.

Do you have any test snippet to reproduce the bug? Thanks.

[vext01]

Hi,

I'm generating these labels from the Rust compiler, which is far from a minimal example.

I'm actually conflicted about what should happen if code containing a label is removed, but the label is marked to be "retained". Maybe it does make sense for those to stay with some kind of a special offset or flag to indicate so. What do you think?

FWIW, my working assumption is that the -unreachableblockelim pass is removing code that contains labels, resulting in 0x0 offsets.

I'll try to get a simple example that gives a label with an 0x0 offset.

[vext01]

Got one!

Here's a dumb program which simply adds 3 to 1 using a function. There is one label in the add_3 function, named XXXYYYZZZ:

; ModuleID = 'mymod'
source_filename = "mymod"

define i32 @add_3(i32 %x) !dbg !3 {
entry:
  %res = add i32 %x, 3, !dbg !9
  call void @llvm.dbg.label(metadata !8), !dbg !9
  ret i32 %res, !dbg !9
}

; Function Attrs: nounwind readnone speculatable
declare void @llvm.dbg.label(metadata) #0

define i32 @main() {
entry:
  %0 = call i32 @add_3(i32 1)
  ret i32 %0
}

attributes #0 = { nounwind readnone speculatable }

!llvm.module.flags = !{!0}
!llvm.dbg.cu = !{!1}

!0 = !{i32 2, !"Debug Info Version", i32 3}
!1 = distinct !DICompileUnit(language: DW_LANG_C, file: !2, producer: "API Example", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug)
!2 = !DIFile(filename: "main.xxx", directory: ".")
!3 = distinct !DISubprogram(name: "add_3", scope: null, file: !2, type: !4, isLocal: false, isDefinition: true, flags: DIFlagPrototyped, isOptimized: false, unit: !1, retainedNodes: !7)
!4 = !DISubroutineType(types: !5)
!5 = !{!6, !6}
!6 = !DIBasicType(name: "u32", size: 32, encoding: DW_ATE_unsigned)
!7 = !{!8}
!8 = !DILabel(scope: !3, name: "XXXYYYZZZ", file: !2, line: 1)
!9 = !DILocation(line: 0, column: 1, scope: !3)

If we compile this (using LLVM just before your change was backed out), and inspect the debuginfo:

$ clang -g -c -O0 -o example.o example.ll
warning: overriding the module target triple with x86_64-unknown-linux-gnu [-Woverride-module]
1 warning generated.
$ dwarfdump example.o
...
< 2><0x00000041>      DW_TAG_label
                        DW_AT_name                  XXXYYYZZZ
                        DW_AT_decl_file             0x00000001 ./main.xxx
                        DW_AT_decl_line             0x00000001
                        DW_AT_low_pc                0x00000000
...

Here we can see that DW_AT_low_pc is 0. What does this mean? Perhaps a bug? The code is clearly not dead, although I would understand if add_3 were inlined. Either way, I'd expect a non-zero low_pc, right?

[HsiangKai]

Hi @vext01,

It should be fixed in https://reviews.llvm.org/D50495.
Please help me to confirm it in your environment. Thanks so much. :)

[sammccall]

The latest reland of this patch triggers a segfault in clang (seemingly only on k8 and ppc).
I've bisected it to r341519 but don't understand the cause.
The stacktrace is:

1.	<eof> parser at end of file
2.	Code generation
#0 0x00005649754494d4 SignalHandler(int) (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0x10db4d4)
#1 0x00007f72c7f849a0 __restore_rt (/usr/grte/v4/lib64/libpthread.so.0+0xf9a0)
#2 0x000056497495f950 llvm::MCObjectStreamer::visitUsedSymbol(llvm::MCSymbol const&) (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0x5f1950)
#3 0x0000564974927858 llvm::MCELFStreamer::EmitValueImpl(llvm::MCExpr const*, unsigned int, llvm::SMLoc) (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0x5b9858)
#4 0x0000564975bdb18c llvm::AddressPool::emit(llvm::AsmPrinter&, llvm::MCSection*) (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0x186d18c)
#5 0x0000564975bb5525 llvm::DwarfDebug::endModule() (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0x1847525)
#6 0x00005649748d185a llvm::AsmPrinter::doFinalization(llvm::Module&) (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0x56385a)
#7 0x000056497535f883 llvm::FPPassManager::doFinalization(llvm::Module&) (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0xff1883)
#8 0x000056497535ff05 llvm::legacy::PassManagerImpl::run(llvm::Module&) (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0xff1f05)
#9 0x0000564974acff27 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0x761f27)
#10 0x00005649764c40cd clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0x21560cd)
#11 0x0000564974cc4f78 clang::ParseAST(clang::Sema&, bool, bool) (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0x956f78)
#12 0x000056497649a3e7 clang::FrontendAction::Execute() (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0x212c3e7)
#13 0x00005649764e1c02 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0x2173c02)
#14 0x000056497683e8b3 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0x24d08b3)
#15 0x00005649754110de cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0x10a30de)
#16 0x0000564974e4682a main (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0xad882a)
#17 0x00007f72c7cf2bbd __libc_start_main (/usr/grte/v4/lib64/libc.so.6+0x38bbd)
#18 0x0000564974e51069 _start (third_party/crosstool/v18/llvm_unstable/toolchain/bin/clang+0xae3069)
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see invocation)

I can try to isolate a reproducer if the buildbots don't pick this up.

[mstorsjo]

The latest reland of this change still causes compilation crashes, see PR 39094. I'll revert this change for now to fix compilation again.

[vitalybuka]

Reverted in r343183
https://bugs.llvm.org/show_bug.cgi?id=39094
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/29356/steps/build%20release%20tsan%20with%20clang/logs/stdio

[HsiangKai]

Fix the bug in https://reviews.llvm.org/D52927.

[HsiangKai]

In D45045#1247427, @vitalybuka wrote:

Reverted in r343183
https://bugs.llvm.org/show_bug.cgi?id=39094
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/29356/steps/build%20release%20tsan%20with%20clang/logs/stdio

I have fixed the bug in D52927 and it has landed in master branch. Could I recommit this patch?

[aprantl]

In D45045#1270442, @HsiangKai wrote:

In D45045#1247427, @vitalybuka wrote:

Reverted in r343183
https://bugs.llvm.org/show_bug.cgi?id=39094
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/29356/steps/build%20release%20tsan%20with%20clang/logs/stdio

I have fixed the bug in D52927 and it has landed in master branch. Could I recommit this patch?

As long as you keep a close eye on the bots that should be fine, yes.

[tyb0807]

Hello all,

This commit has been reverted by rC345026. It was reported that this broke the Chromium build (again). Have you had a look to fix this, @HsiangKai?

[HsiangKai]

In D45045#1299507, @tyb0807 wrote:

Hello all,

This commit has been reverted by rC345026. It was reported that this broke the Chromium build (again). Have you had a look to fix this, @HsiangKai?

I have fixed these bugs found in Chromium build in following two commits.

https://reviews.llvm.org/D54199
https://reviews.llvm.org/D54465

These two commits are under reviewing.
Thanks for your reminding.

[HsiangKai]

D54199 and D54465 have been accepted and landed. I have tested the revision with LLVM test and Clang test. They are all passed. Chromium build is also successful in my local environment. I think it is ready to reland the revision.

lib/CodeGen/CGDebugInfo.h

public:
   /// Emit call to \c llvm.dbg.declare for an automatic variable
   /// declaration.
   /// Returns a pointer to the DILocalVariable associated with the
   /// llvm.dbg.declare, or nullptr otherwise.
   llvm::DILocalVariable *EmitDeclareOfAutoVariable(const VarDecl *Decl,
                                                    llvm::Value *AI,
                                                    CGBuilderTy &Builder);
 
+  /// Emit call to \c llvm.dbg.label for an label.
+  void EmitLabel(const LabelDecl *D, CGBuilderTy &Builder);
+
   /// Emit call to \c llvm.dbg.declare for an imported variable
   /// declaration in a block.
   void EmitDeclareOfBlockDeclRefVariable(const VarDecl *variable,
                                          llvm::Value *storage,
                                          CGBuilderTy &Builder,
                                          const CGBlockInfo &blockInfo,
                                          llvm::Instruction *InsertPoint = nullptr);
 

lib/CodeGen/CGDebugInfo.cpp

 
 llvm::DILocalVariable *
 CGDebugInfo::EmitDeclareOfAutoVariable(const VarDecl *VD, llvm::Value *Storage,
                                        CGBuilderTy &Builder) {
   assert(DebugKind >= codegenoptions::LimitedDebugInfo);
   return EmitDeclare(VD, Storage, llvm::None, Builder);
 }
 
+void CGDebugInfo::EmitLabel(const LabelDecl *D, CGBuilderTy &Builder) {
+  assert(DebugKind >= codegenoptions::LimitedDebugInfo);
+  assert(!LexicalBlockStack.empty() && "Region stack mismatch, stack empty!");
+
+  if (D->hasAttr<NoDebugAttr>())
+    return;
+
+  auto *Scope = cast<llvm::DIScope>(LexicalBlockStack.back());
+  llvm::DIFile *Unit = getOrCreateFile(D->getLocation());
+
+  // Get location information.
+  unsigned Line = getLineNumber(D->getLocation());
+  unsigned Column = getColumnNumber(D->getLocation());
+
+  StringRef Name = D->getName();
+
+  // Create the descriptor for the label.
+  auto *L =
+      DBuilder.createLabel(Scope, Name, Unit, Line, CGM.getLangOpts().Optimize);
+
+  // Insert an llvm.dbg.label into the current block.
+  DBuilder.insertLabel(L,
+                       llvm::DebugLoc::get(Line, Column, Scope, CurInlinedAt),
+                       Builder.GetInsertBlock());
+}
+
 llvm::DIType *CGDebugInfo::CreateSelfType(const QualType &QualTy,
                                           llvm::DIType *Ty) {
   llvm::DIType *CachedTy = getTypeOrNull(QualTy);
   if (CachedTy)
     Ty = CachedTy;
   return DBuilder.createObjectPointerType(Ty);
 }
 

lib/CodeGen/CGStmt.cpp

void CodeGenFunction::EmitLabel(const LabelDecl *D) {
   // it from the branch-fixups list.
   } else {
     assert(!Dest.getScopeDepth().isValid() && "already emitted label!");
     Dest.setScopeDepth(EHStack.stable_begin());
     ResolveBranchFixups(Dest.getBlock());
   }
 
   EmitBlock(Dest.getBlock());
+
+  // Emit debug info for labels.
+  if (CGDebugInfo *DI = getDebugInfo()) {
+    if (CGM.getCodeGenOpts().getDebugInfo() >=
+        codegenoptions::LimitedDebugInfo) {
+      DI->setLocation(D->getLocation());
+      DI->EmitLabel(D, Builder);
+    }
+  }
+
   incrementProfileCounter(D->getStmt());
 }
 
 /// Change the cleanup scope of the labels in this lexical scope to
 /// match the scope of the enclosing context.
 void CodeGenFunction::LexicalScope::rescopeLabels() {
   assert(!Labels.empty());
   EHScopeStack::stable_iterator innermostScope

test/CodeGen/backend-unsupported-error.ll

 
 !llvm.dbg.cu = !{!0}
 !llvm.module.flags = !{!9, !10}
 !llvm.ident = !{!11}
 
 !0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 3.9.0", isOptimized: false, runtimeVersion: 0, emissionKind: 1, enums: !2)
 !1 = !DIFile(filename: "test.c", directory: "")
 !2 = !{}
-!4 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 2, type: !5, isLocal: false, isDefinition: true, scopeLine: 2, isOptimized: false, unit: !0, variables: !2)
+!4 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 2, type: !5, isLocal: false, isDefinition: true, scopeLine: 2, isOptimized: false, unit: !0, retainedNodes: !2)
 !5 = !DISubroutineType(types: !6)
 !6 = !{!7}
 !7 = !DIBasicType(name: "int", size: 32, align: 32, encoding: DW_ATE_signed)
-!8 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 3, type: !5, isLocal: false, isDefinition: true, scopeLine: 3, flags: DIFlagPrototyped, isOptimized: false, unit: !0, variables: !2)
+!8 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 3, type: !5, isLocal: false, isDefinition: true, scopeLine: 3, flags: DIFlagPrototyped, isOptimized: false, unit: !0, retainedNodes: !2)
 !9 = !{i32 2, !"Dwarf Version", i32 4}
 !10 = !{i32 2, !"Debug Info Version", i32 3}
 !11 = !{!"clang version 3.9.0"}
 !12 = !DILocation(line: 2, column: 20, scope: !4)
 !13 = !DILocation(line: 2, column: 13, scope: !4)
 !14 = !DILocation(line: 3, column: 20, scope: !8)
 !15 = !DILocation(line: 3, column: 13, scope: !8)

test/CodeGen/debug-label-inline.c

+// This test will test the correctness of generating DILabel and
+// llvm.dbg.label when the label is in inlined functions.
+//
+// RUN: %clang_cc1 -O2 %s -o - -emit-llvm -debug-info-kind=limited | FileCheck %s
+inline int f1(int a, int b) {
+  int sum;
+
+top:
+  sum = a + b;
+  return sum;
+}
+
+extern int ga, gb;
+
+int f2(void) {
+  int result;
+
+  result = f1(ga, gb);
+  // CHECK: call void @llvm.dbg.label(metadata [[LABEL_METADATA:!.*]]), !dbg [[LABEL_LOCATION:!.*]]
+
+  return result;
+}
+
+// CHECK: distinct !DISubprogram(name: "f1", {{.*}}, retainedNodes: [[ELEMENTS:!.*]])
+// CHECK: [[ELEMENTS]] = !{{{.*}}, [[LABEL_METADATA]]}
+// CHECK: [[LABEL_METADATA]] = !DILabel({{.*}}, name: "top", {{.*}}, line: 8)
+// CHECK: [[INLINEDAT:!.*]] = distinct !DILocation(line: 18,
+// CHECK: [[LABEL_LOCATION]] = !DILocation(line: 8, {{.*}}, inlinedAt: [[INLINEDAT]])

test/CodeGen/debug-label.c

+// This test will test the correstness of generating DILabel and
+// llvm.dbg.label for labels.
+//
+// RUN: %clang_cc1 -emit-llvm %s -o - -emit-llvm -debug-info-kind=limited | FileCheck %s
+
+int f1(int a, int b) {
+  int sum;
+
+top:
+  // CHECK: call void @llvm.dbg.label(metadata [[LABEL_METADATA:!.*]]), !dbg [[LABEL_LOCATION:!.*]]
+  sum = a + b;
+  return sum;
+}
+
+// CHECK: [[LABEL_METADATA]] = !DILabel({{.*}}, name: "top", {{.*}}, line: 9)
+// CHECK: [[LABEL_LOCATION]] = !DILocation(line: 9,