Show register names in DWARF unwind info.

[clayborg]

Summary

Register context information was already being passed into the DWARFDebugFrame code that dumps unwind information but it wasn't being used. This change adds the ability to dump registers names of a valid MC register context was passed in and if it knows about the register. Updated the tests to use the newly returned register names.

[clayborg]

Removed a change to DwarfTransformer.cpp that wasn't part of this patch.

[clayborg]

Fix test failures found by harbormaster.

[aprantl]

Nice!

[JamesNagurne]

In llvm/test/DebugInfo/dwarfdump-debug-frame-simple.test

Our team maintains a downstream ARM target. The compiler, and indeed llvm-dwarfdump, are not built with the target used to build the object file queried here. Therefore, it does not know to use ESP or EIP and dumps reg4/reg8 instead.
Has any other downstream compiler seen this? I'm not able to access the buildbots right at the moment.

Specifically, here's the output from our lit test run with this change integrated into our downstream build:

llvm/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o: No available targets are compatible with triple "i386-unknown-unknown"
llvm/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o:	file format elf32-i386

.debug_frame contents:

00000000 00000010 ffffffff CIE
  Format:                DWARF32
  Version:               1
  Augmentation:          ""
  Code alignment factor: 1
  Data alignment factor: -4
  Return address column: 8

  DW_CFA_def_cfa: reg4 +4
  DW_CFA_offset: reg8 -4
  DW_CFA_nop:
  DW_CFA_nop:

I suspect that if we really desire ESP/EIP, the test will need to be excluded when the i386 target is not available.

[clayborg]

In D88767#2315279, @JamesNagurne wrote:

In llvm/test/DebugInfo/dwarfdump-debug-frame-simple.test

Our team maintains a downstream ARM target. The compiler, and indeed llvm-dwarfdump, are not built with the target used to build the object file queried here. Therefore, it does not know to use ESP or EIP and dumps reg4/reg8 instead.
Has any other downstream compiler seen this? I'm not able to access the buildbots right at the moment.

Specifically, here's the output from our lit test run with this change integrated into our downstream build:

llvm/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o: No available targets are compatible with triple "i386-unknown-unknown"
llvm/test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o:	file format elf32-i386

.debug_frame contents:

00000000 00000010 ffffffff CIE
  Format:                DWARF32
  Version:               1
  Augmentation:          ""
  Code alignment factor: 1
  Data alignment factor: -4
  Return address column: 8

  DW_CFA_def_cfa: reg4 +4
  DW_CFA_offset: reg8 -4
  DW_CFA_nop:
  DW_CFA_nop:

I suspect that if we really desire ESP/EIP, the test will need to be excluded when the i386 target is not available.

Or this could be switched to a regex that accepts "reg4" or "ESP" or "reg8" or "EIP"?

[clayborg]

I made a patch to fix buildbots that don't compile in certain architectures with https://reviews.llvm.org/D88940

[awarzynski]

In D88767#2315748, @clayborg wrote:

I made a patch to fix buildbots that don't compile in certain architectures with https://reviews.llvm.org/D88940

@clayborg Our Flang-AArch64 buildbots have been failing due to this: http://lab.llvm.org:8011/#/builders/34/builds/13. Please, could this be either reverted or the other patch merged? Thanks!

[clayborg]

In D88767#2316092, @awarzynski wrote:

In D88767#2315748, @clayborg wrote:

I made a patch to fix buildbots that don't compile in certain architectures with https://reviews.llvm.org/D88940

@clayborg Our Flang-AArch64 buildbots have been failing due to this: http://lab.llvm.org:8011/#/builders/34/builds/13. Please, could this be either reverted or the other patch merged? Thanks!

I didn't see any failures on the llvm buildbots that email me when they fail. The other patch will be merged as soon as accepted. Should be tomorrow morning.

[awarzynski]

@clayborg Our Flang-AArch64 buildbots have been failing due to this: http://lab.llvm.org:8011/#/builders/34/builds/13. Please, could this be either reverted or the other patch merged? Thanks!

I didn't see any failures on the llvm buildbots that email me when they fail. The other patch will be merged as soon as accepted. Should be tomorrow morning.

Thanks! I think that the buildbot master was restarted recently and hence our worker wasn't able to generate an accurate blamelist. Otherwise everything seems fine.

[clayborg]

In D88767#2316169, @awarzynski wrote:

@clayborg Our Flang-AArch64 buildbots have been failing due to this: http://lab.llvm.org:8011/#/builders/34/builds/13. Please, could this be either reverted or the other patch merged? Thanks!

I didn't see any failures on the llvm buildbots that email me when they fail. The other patch will be merged as soon as accepted. Should be tomorrow morning.

Thanks! I think that the buildbot master was restarted recently and hence our worker wasn't able to generate an accurate blamelist. Otherwise everything seems fine.

Fixed with https://reviews.llvm.org/D88940. Let me know if this fixes things on your end!

[awarzynski]

In D88767#2318316, @clayborg wrote:

In D88767#2316169, @awarzynski wrote:

@clayborg Our Flang-AArch64 buildbots have been failing due to this: http://lab.llvm.org:8011/#/builders/34/builds/13. Please, could this be either reverted or the other patch merged? Thanks!

I didn't see any failures on the llvm buildbots that email me when they fail. The other patch will be merged as soon as accepted. Should be tomorrow morning.

Thanks! I think that the buildbot master was restarted recently and hence our worker wasn't able to generate an accurate blamelist. Otherwise everything seems fine.

Fixed with https://reviews.llvm.org/D88940. Let me know if this fixes things on your end!

All good, thank you!

llvm/lib/DebugInfo/DWARF/DWARFDebugFrame.cpp

 //===- DWARFDebugFrame.h - Parsing of .debug_frame ------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "llvm/DebugInfo/DWARF/DWARFDebugFrame.h"
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/BinaryFormat/Dwarf.h"
+#include "llvm/MC/MCRegisterInfo.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/DataExtractor.h"
 #include "llvm/Support/Errc.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/Format.h"
 #include "llvm/Support/raw_ostream.h"
 #include <algorithm>
 #include <cassert>
 #include <cinttypes>
 #include <cstdint>
 #include <string>
 #include <vector>
 
 using namespace llvm;
 using namespace dwarf;
 
+static void printRegister(raw_ostream &OS, const MCRegisterInfo *MRI, bool IsEH,
+                          unsigned RegNum) {
+  if (MRI) {
+    if (Optional<unsigned> LLVMRegNum = MRI->getLLVMRegNum(RegNum, IsEH)) {
+      if (const char *RegName = MRI->getName(*LLVMRegNum)) {
+        OS << RegName;
+        return;
+      }
+    }
+  }
+  OS << "reg" << RegNum;
+}
 
 // See DWARF standard v3, section 7.23
 const uint8_t DWARF_CFI_PRIMARY_OPCODE_MASK = 0xc0;
 const uint8_t DWARF_CFI_PRIMARY_OPERAND_MASK = 0x3f;
 
 Error CFIProgram::parse(DWARFDataExtractor Data, uint64_t *Offset,
                         uint64_t EndOffset) {
   DataExtractor::Cursor C(*Offset);
case OT_SignedFactDataOffset:
     break;
   case OT_UnsignedFactDataOffset:
     if (DataAlignmentFactor)
       OS << format(" %" PRId64, Operand * DataAlignmentFactor);
     else
       OS << format(" %" PRId64 "*data_alignment_factor" , Operand);
     break;
   case OT_Register:
-    OS << format(" reg%" PRId64, Operand);
+    OS << ' ';
+    printRegister(OS, MRI, IsEH, Operand);
     break;
   case OT_Expression:
     assert(Instr.Expression && "missing DWARFExpression object");
     OS << " ";
     Instr.Expression->print(OS, MRI, nullptr, IsEH);
     break;
   }
 }

llvm/test/DebugInfo/dwarfdump-debug-frame-simple.test

 ; RUN: llvm-dwarfdump %p/Inputs/dwarfdump-test-32bit.elf.o --debug-frame | FileCheck %s -check-prefix FRAMES
 ; Note: the input file was generated from Inputs/dwarfdump-test-32bit.elf.c
 
 ; FRAMES: .debug_frame
 
 ; FRAMES: 00000000 00000010 ffffffff CIE
 ; FRAMES: Version: 1
-; FRAMES:      DW_CFA_def_cfa: reg4 +4
-; FRAMES-NEXT: DW_CFA_offset: reg8 -4
+; FRAMES:      DW_CFA_def_cfa: ESP +4
+; FRAMES-NEXT: DW_CFA_offset: EIP -4
 ; FRAMES-NEXT: DW_CFA_nop:
 ; FRAMES-NEXT: DW_CFA_nop:
 
 ; FRAMES: 00000014 00000010 00000000 FDE cie=00000000 pc=00000000...00000022
 ; FRAMES:      DW_CFA_advance_loc: 3
 ; FRAMES-NEXT: DW_CFA_def_cfa_offset: +12
 ; FRAMES-NEXT: DW_CFA_nop:
 
 ; FRAMES: 00000028 00000014 00000000 FDE cie=00000000 pc=00000030...00000080
 ; FRAMES:      DW_CFA_advance_loc: 1
 ; FRAMES-NEXT: DW_CFA_def_cfa_offset: +8
-; FRAMES-NEXT: DW_CFA_offset: reg5 -8
+; FRAMES-NEXT: DW_CFA_offset: EBP -8
 ; FRAMES-NEXT: DW_CFA_advance_loc: 2
-; FRAMES-NEXT: DW_CFA_def_cfa_register: reg5
+; FRAMES-NEXT: DW_CFA_def_cfa_register: EBP
 
 ; FRAMES-NOT: CIE
 ; FRAMES-NOT: FDE
 ; FRAMES: .eh_frame

llvm/test/MC/ELF/cfi-restore-extended.s

 // RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux-gnu %s -o - | llvm-dwarfdump -debug-frame - | FileCheck %s
 
 // Check that register numbers greater than 63 can be used in .cfi_restore directives
 f:
   .cfi_startproc
   nop
 // CHECK: DW_CFA_advance_loc: 1
   .cfi_restore %rbp
-// CHECK-NEXT: DW_CFA_restore: reg6
+// CHECK-NEXT: DW_CFA_restore: RBP
   nop
 // CHECK-NEXT: DW_CFA_advance_loc: 1
   .cfi_restore 89
 // CHECK-NEXT: DW_CFA_restore_extended: reg89
 // CHECK-NEXT: DW_CFA_nop:
   nop
   .cfi_endproc
-

llvm/test/MC/X86/i386-darwin-frame-register.ll

 ; RUN: llc -filetype=obj %s -o - | llvm-dwarfdump -debug-frame - | FileCheck %s
 
 ; IR reduced from a dummy:
 ; void foo() {}
 
 ; x86 Darwin uses different register mappings for eh_frame and debug_frame
 ; sections. Check that the right mapping is used in debug_frame.
 ; In the debug_frame mapping, register 4 is ESP, thus the below tests that
 ; the CFA is ESP+4 upon function entry.
 
 ; CHECK: .debug_frame contents:
 ; CHECK: ffffffff CIE
 ; CHECK-NOT: {{CIE|FDE}}
-; CHECK:   DW_CFA_def_cfa: reg4 +4
+; CHECK:   DW_CFA_def_cfa: ESP +4
 
 ; ModuleID = 'foo.c'
 target datalayout = "e-m:o-p:32:32-f64:32:64-f80:128-n8:16:32-S128"
 target triple = "i386-apple-macosx10.10.0"
 
 ; Function Attrs: nounwind ssp
 define void @foo() #0 {
 entry: