[COFF, ARM64] Fix CodeView API change for getRegisterNames

[TomTan]

Summary

Change rL362280 changed CodeView API getRegisterNames() by adding an input parameter in CPUType. It is called in LLDB and needs to be updated.

[mgorny]

Are you sure this triple → CPUType mapping belongs in each consumer? Maybe it'd be better to have something inside LLVM, so that we wouldn't have to keep this up-to-date in all the places. Maybe getRegisterNames() overload that takes a triple?

[TomTan]

Update variable naming to be consistent with current file.

[TomTan]

In D62772#1526145, @mgorny wrote:

Are you sure this triple → CPUType mapping belongs in each consumer? Maybe it'd be better to have something inside LLVM, so that we wouldn't have to keep this up-to-date in all the places. Maybe getRegisterNames() overload that takes a triple?

The CodeView APIs seems not aware of LLVM tripe. CPUType comes from CodeView which makes this API self-consistent.

[jankratochvil]

D62771 does address the same.

[aganea]

source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp

29 ↗

(On Diff #202540)

Shouldn’t ArchType::aarch64_be and ArchType::aarch64_32 enums be handled here as well?

32 ↗

(On Diff #202540)

Intel80386 for consistency?

[compnerd]

source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp

29 ↗

(On Diff #202540)

I think that we should use a switch to cover the targets. /Oy will allow FPO on x86 as well. There is also WoA (ARM32).

[TomTan]

source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp

29 ↗

(On Diff #202540)

Seems no, aarch64_be or aarch64_32 is not supported by CodeView or Windows.

32 ↗

(On Diff #202540)

x86 and x64 are handled as the same CPUType by CodeView. LLVM pdb dump tool also sets X64 as default.

[TomTan]

Change to switch/case based on comment.

[TomTan]

source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp

29 ↗

(On Diff #202540)

Ok. It makes sense to use switch/case. CodeView doesn't support WoA (ARM32) so no need to add case for it here.

[compnerd]

This should get the build working again, so lets get this fixed, we can improve it later

source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp

29 ↗

(On Diff #202540)

Huh? How does cl generate that then?

[TomTan]

In D62772#1526824, @compnerd wrote:

This should get the build working again, so lets get this fixed, we can improve it later

Thanks, committed the fix to unblock build. For WoA(ARM32) which is not supported, I meant LLVM CodeView, not CodeView specification. llvm::codeview::getRegisterNames(cpu_type) will return incorrect register name even the right CPUType is passed in for WoA(ARM32), because it has not been implemented in LLVM CodeView yet.

lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp

 #include "llvm/DebugInfo/CodeView/EnumTables.h"
 
 using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::postfix;
 
 static uint32_t ResolveLLDBRegisterNum(llvm::StringRef reg_name, llvm::Triple::ArchType arch_type) {
   // lookup register name to get lldb register number
+  llvm::codeview::CPUType cpu_type;
+  switch (arch_type) {
+    case llvm::Triple::ArchType::aarch64:
+      cpu_type = llvm::codeview::CPUType::ARM64;
+      break;
+
+    default:
+      cpu_type = llvm::codeview::CPUType::X64;
+      break;
+  }
+
   llvm::ArrayRef<llvm::EnumEntry<uint16_t>> register_names =
-      llvm::codeview::getRegisterNames();
+      llvm::codeview::getRegisterNames(cpu_type);
   auto it = llvm::find_if(
       register_names,
       [&reg_name](const llvm::EnumEntry<uint16_t> &register_entry) {
         return reg_name.compare_lower(register_entry.Name) == 0;
       });
 
   if (it == register_names.end())
     return LLDB_INVALID_REGNUM;