Skip to content

[DebugInfo] Move codeview::SourceLanguage enumerators to CodeViewLanguages.def (NFC) #141750

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jalopezg-git
Copy link
Contributor

Per @CarlosAlbertoEnciso comment, this change was split from its original PR #137223. In his own words,

I think this is good change, but it should be done in another PR (before the current one) and get the feedback from the
CodeView teams. In that way it would be a global benefit for other tools (including llvm-debuginfo-analyzer).

This PR proposes moving out enumerators for codeview::SourceLanguage to a separate CodeViewLanguages.def file, following the same guideline that in other parts of LLVM, and in particular the TypeRecordKind (enumerators in CodeViewTypes.def) or SymbolRecordKind (enumerators in CodeViewSymbols.def).

This is a non-functional change, and has been labeled as such. This change helps for #137223, and possibly other future changes.

FYI, @CarlosAlbertoEnciso.

@llvmbot
Copy link
Member

llvmbot commented May 28, 2025

@llvm/pr-subscribers-debuginfo

Author: Javier Lopez-Gomez (jalopezg-git)

Changes

Per @CarlosAlbertoEnciso comment, this change was split from its original PR #137223. In his own words,
> I think this is good change, but it should be done in another PR (before the current one) and get the feedback from the
> CodeView teams. In that way it would be a global benefit for other tools (including llvm-debuginfo-analyzer).

This PR proposes moving out enumerators for codeview::SourceLanguage to a separate CodeViewLanguages.def file, following the same guideline that in other parts of LLVM, and in particular the TypeRecordKind (enumerators in CodeViewTypes.def) or SymbolRecordKind (enumerators in CodeViewSymbols.def).

This is a non-functional change, and has been labeled as such. This change helps for #137223, and possibly other future changes.

FYI, @CarlosAlbertoEnciso.


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

2 Files Affected:

  • (modified) llvm/include/llvm/DebugInfo/CodeView/CodeView.h (+2-30)
  • (added) llvm/include/llvm/DebugInfo/CodeView/CodeViewLanguages.def (+51)
diff --git a/llvm/include/llvm/DebugInfo/CodeView/CodeView.h b/llvm/include/llvm/DebugInfo/CodeView/CodeView.h
index 5cdff5ff0e82f..12d589db03b25 100644
--- a/llvm/include/llvm/DebugInfo/CodeView/CodeView.h
+++ b/llvm/include/llvm/DebugInfo/CodeView/CodeView.h
@@ -144,36 +144,8 @@ enum class CPUType : uint16_t {
 /// Debug Interface Access SDK, and are documented here:
 /// https://learn.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/cv-cfl-lang
 enum SourceLanguage : uint8_t {
-  C = 0x00,
-  Cpp = 0x01,
-  Fortran = 0x02,
-  Masm = 0x03,
-  Pascal = 0x04,
-  Basic = 0x05,
-  Cobol = 0x06,
-  Link = 0x07,
-  Cvtres = 0x08,
-  Cvtpgd = 0x09,
-  CSharp = 0x0a,
-  VB = 0x0b,
-  ILAsm = 0x0c,
-  Java = 0x0d,
-  JScript = 0x0e,
-  MSIL = 0x0f,
-  HLSL = 0x10,
-  ObjC = 0x11,
-  ObjCpp = 0x12,
-  Swift = 0x13,
-  AliasObj = 0x14,
-  Rust = 0x15,
-  Go = 0x16,
-
-  /// The DMD compiler emits 'D' for the CV source language. Microsoft does not
-  /// have an enumerator for it yet.
-  D = 'D',
-  /// The Swift compiler used to emit 'S' for the CV source language, but
-  /// current versions emit the enumerator defined above.
-  OldSwift = 'S',
+#define CV_LANGUAGE(NAME, ID) NAME = ID,
+#include "CodeViewLanguages.def"
 };
 
 /// These values correspond to the CV_call_e enumeration, and are documented
diff --git a/llvm/include/llvm/DebugInfo/CodeView/CodeViewLanguages.def b/llvm/include/llvm/DebugInfo/CodeView/CodeViewLanguages.def
new file mode 100644
index 0000000000000..5c6335fffd4dd
--- /dev/null
+++ b/llvm/include/llvm/DebugInfo/CodeView/CodeViewLanguages.def
@@ -0,0 +1,51 @@
+//===-- CodeViewLanguages.def - All CodeView languages ----------*- C++ -*-===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+//
+// These values correspond to the CV_CFL_LANG enumeration in the Microsoft
+// Debug Interface Access SDK, and are documented here:
+// https://learn.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/cv-cfl-lang
+// This should match the constants there.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef CV_LANGUAGE
+#define CV_LANGUAGE(NAME, ID)
+#endif
+
+CV_LANGUAGE(C, 0x00)
+CV_LANGUAGE(Cpp, 0x01)
+CV_LANGUAGE(Fortran, 0x02)
+CV_LANGUAGE(Masm, 0x03)
+CV_LANGUAGE(Pascal, 0x04)
+CV_LANGUAGE(Basic, 0x05)
+CV_LANGUAGE(Cobol, 0x06)
+CV_LANGUAGE(Link, 0x07)
+CV_LANGUAGE(Cvtres, 0x08)
+CV_LANGUAGE(Cvtpgd, 0x09)
+CV_LANGUAGE(CSharp, 0x0a)
+CV_LANGUAGE(VB, 0x0b)
+CV_LANGUAGE(ILAsm, 0x0c)
+CV_LANGUAGE(Java, 0x0d)
+CV_LANGUAGE(JScript, 0x0e)
+CV_LANGUAGE(MSIL, 0x0f)
+CV_LANGUAGE(HLSL, 0x10)
+CV_LANGUAGE(ObjC, 0x11)
+CV_LANGUAGE(ObjCpp, 0x12)
+CV_LANGUAGE(Swift, 0x13)
+CV_LANGUAGE(AliasObj, 0x14)
+CV_LANGUAGE(Rust, 0x15)
+CV_LANGUAGE(Go, 0x16)
+
+// The DMD compiler emits 'D' for the CV source language. Microsoft does not
+// have an enumerator for it yet.
+CV_LANGUAGE(D, 'D')
+// The Swift compiler used to emit 'S' for the CV source language, but
+// current versions emit the enumerator defined above.
+CV_LANGUAGE(OldSwift, 'S')
+
+#undef CV_LANGUAGE

@jalopezg-git jalopezg-git force-pushed the jalopezg-codeview-sourcelanguage-def branch from 6953325 to 7e3ca81 Compare May 28, 2025 13:32
@dwblaikie
Copy link
Collaborator

@zmodem for CodeView things, maybe - or might know other folks interested in it.

@CarlosAlbertoEnciso CarlosAlbertoEnciso requested review from rnk and removed request for rnk May 29, 2025 04:32
@CarlosAlbertoEnciso
Copy link
Member

Maybe @rnk for CodeView related work.

Copy link
Collaborator

@zmodem zmodem left a comment

Choose a reason for hiding this comment

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

LLVM does this a lot, but I think there has to be some benefit, otherwise it's just extra indirection over a having a regular enum.

I don't know if the enum you're creating in #137223 is enough of a motivation. Does it really have much benefit over just storing the original enum values + tag in an unsigned? The new enum seems to be mostly used by looking at the tag and then casting to one of the original enums anyway.

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.

5 participants