[LLDB][Windows] Handle C calling convention mangling

[Nerixyz]

On Windows, C functions can be mangled/decorated based on the calling convention. See Microsoft docs. A complication is that this is dependent on the environment (x86 vs. amd64 vs. ARM). Take the following example:

extern "C" {
int /* __cdecl (default) */ FuncCCall() { return 0; }
int __stdcall FuncStdCall() { return 0; }
int __fastcall FuncFastCall() { return 0; }
int __vectorcall FuncVectorCall() { return 0; }
}

Function Name	Mangled Name (x86)	Mangled Name (amd64/x86_64)	Mangled Name (ARM)
FuncCCall	_FuncCCall	FuncCCall	FuncCCall
FuncStdCall	_FuncStdCall@0	FuncStdCall	FuncStdCall
FuncFastCall	@FuncFastCall@0	FuncFastCall	FuncFastCall
FuncVectorCall	FuncVectorCall@@0	FuncVectorCall@@0	FuncVectorCall

Additionally, FuncCCall shows up as FuncCCall on x86 when using DWARF (instead of _FuncCCall):

0x0000009c: DW_TAG_subprogram
              DW_AT_low_pc	(0x00000000)
              DW_AT_high_pc	(0x00000007)
              DW_AT_frame_base	(DW_OP_reg5 EBP)
              DW_AT_name	("CFuncCCall")
              DW_AT_decl_file	("/app/example.cpp")
              DW_AT_decl_line	(2)
              DW_AT_type	(0x00000041 "int")
              DW_AT_external	(true)

From https://godbolt.org/z/TzcqWPd8j (see also discussion in #160930).

On PDB, in the publics stream, however, the "true" mangled name (_FuncCCall) shows.

As of (PR TBD), the native PDB plugin will strip the leading underscore from the function symbol to match DWARF.

We should still strip these pre-/suffixes somewhere, because currently, functions will show up with the mangled name. Note that the mangling might be nested. For example, on x86, __Z7recursei is a __cdecl function (leading underscore) and the rest is a mangled itanium name.

[llvmbot]

@llvm/issue-subscribers-lldb

Author: nerix (Nerixyz)

On Windows, C functions can be mangled/decorated based on the calling convention. See [Microsoft docs](https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names#FormatC). A complication is that this is dependent on the environment (32 vs. 64 bit). Take the following example:

extern "C" {
int /* __cdecl (default) */ FuncCCall() { return 0; }
int __stdcall FuncStdCall() { return 0; }
int __fastcall FuncFastCall() { return 0; }
int __vectorcall FuncVectorCall() { return 0; }
}

Function Name	Mangled Name (32 bit)	Mangled Name (64 bit)
FuncCCall	_FuncCCall	FuncCCall
FuncStdCall	_FuncStdCall@<!-- -->0	FuncStdCall
FuncFastCall	@<!-- -->FuncFastCall@<!-- -->0	FuncFastCall
FuncVectorCall	FuncVectorCall@@<!-- -->0	FuncVectorCall@@<!-- -->0

Additionally, FuncCCall shows up as FuncCCall on 32 bit when using DWARF (instead of _FuncCCall):

0x0000009c: DW_TAG_subprogram
              DW_AT_low_pc	(0x00000000)
              DW_AT_high_pc	(0x00000007)
              DW_AT_frame_base	(DW_OP_reg5 EBP)
              DW_AT_name	("CFuncCCall")
              DW_AT_decl_file	("/app/example.cpp")
              DW_AT_decl_line	(2)
              DW_AT_type	(0x00000041 "int")
              DW_AT_external	(true)

From https://godbolt.org/z/TzcqWPd8j (see also discussion in #160930).

On PDB, in the publics stream, however, the "true" mangled name (_FuncCCall) shows.

As of (PR TBD), the native PDB plugin will strip the leading underscore from the function symbol to match DWARF.

We should still strip these pre-/suffixes somewhere, because currently, functions will show up with the mangled name. Note that the mangling might be nested. For example, on x86, __Z7recursei is a __cdecl function (leading underscore) and the rest is a mangled itanium name.

[Michael137]

Thanks for filing this.

Copying my comment from #160930 (comment)

Basically what ends up in DWARF as DW_AT_linkage_name is whatever the Clang AST mangled to. It follows the Itanium spec for C++ names (and C names are just not mangled). The _ prefix that some platforms add is outside the purview of the spec (unless we're on Windows and have a __stdcall attribute on the function). In my opinion the DW_AT_linkage_name that Clang emits should have been the linkage name that ends up in the object files. But Clang and GCC put the platform independent C++ mangled names into it. Not something we can change at this point (I think), but this is where the discrepancy comes from; the compiler conflates "linkage name" and "Itanium mangled name". For Mach-O, where we have the _ prefix too, LLDB strips the prefix when parsing the symbol table (it's mentioned in several places in the Mach-O parser):

llvm-project/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp

Lines 3572 to 3582 in 4ec6d12

	if (add_nlist) {
	uint64_t symbol_value = nlist.n_value;
	if (symbol_name_non_abi_mangled) {
	sym[sym_idx].GetMangled().SetMangledName(
	ConstString(symbol_name_non_abi_mangled));
	sym[sym_idx].GetMangled().SetDemangledName(
	ConstString(symbol_name));
	} else {
	if (symbol_name && symbol_name[0] == '_') {
	symbol_name++; // Skip the leading underscore
	}

[Michael137]

Additionally, FuncCCall shows up as FuncCCall on x86 when using DWARF (instead of _FuncCCall):

This technically aligns with how we generate linkage names for C++. But yes, the real linkage name has the _ prefix. We decide the DW_AT_linkage_name before we actually add the global prefix to the name in the LLVM backend.