A few of lldb's frame formatting function options do not work on Windows

[DavidSpickett]

Found while fixing #142952, but really this has been going on for a while.

function.name and function.name-without-args don't work on Windows because there we thinks that the function's "name" is void fn(void) instead of just fn.

For example:

C:\Users\tcwg>cat test.cpp
void fn0() {}
void fn1() { fn0();}
int main() { fn1(); return 0; }

This is the default backtrace:

lldb.exe test.exe
(lldb) target create "test.exe"
Current executable set to 'C:\Users\tcwg\test.exe' (aarch64).
(lldb) b fn0
Breakpoint 1: where = test.exe`void __cdecl fn0(void) at test.cpp:1, address = 0x00000001400148c0
(lldb) run
Process 5632 launched: 'C:\Users\tcwg\test.exe' (aarch64)
Process 5632 stopped
* thread #1, stop reason = breakpoint 1.1
    frame #0: 0x00007ff6483248c0 test.exe`void __cdecl fn0(void) at test.cpp:1
-> 1    void fn0() {}
   2    void fn1() { fn0();}
   3    int main() { fn1(); return 0; }
   4
(lldb) bt
* thread #1, stop reason = breakpoint 1.1
  * frame #0: 0x00007ff6483248c0 test.exe`void __cdecl fn0(void) at test.cpp:1
    frame #1: 0x00007ff6483248d4 test.exe`void __cdecl fn1(void) at test.cpp:2
    frame #2: 0x00007ff6483248ec test.exe`main at test.cpp:3
    frame #3: 0x00007ff648324838 test.exe`static int __scrt_common_main_seh() at exe_common.inl:288
    frame #4: 0x00007ff648324d3c test.exe`mainCRTStartup(__formal=<unavailable>) at exe_main.cpp:16
    frame #5: 0x00007ff9efe52310 kernel32.dll`BaseThreadInitThunk + 48
    frame #6: 0x00007ff9f3a15aec ntdll.dll`RtlUserThreadStart + 60

Note that some functions lack arguments, I don't know why.

function.name does not remove the return type or parameters for some functions:

(lldb) settings set frame-format "'${function.name}'\n"
(lldb) bt
* thread #1, stop reason = breakpoint 1.1
  * 'void __cdecl fn0(void)'
    'void __cdecl fn1(void)'
    'main'
    'static int __scrt_common_main_seh()'
    'mainCRTStartup'
    'BaseThreadInitThunk'
    'RtlUserThreadStart'

function.mangled-name works:

(lldb) settings set frame-format "'${function.mangled-name}'\n"
(lldb) bt
* thread #1, stop reason = breakpoint 1.1
  * '?fn0@@YAXXZ'
    '?fn1@@YAXXZ'
    'main'
    'static int __scrt_common_main_seh()'
    'mainCRTStartup'
    'BaseThreadInitThunk'
    'RtlUserThreadStart'

function.name-with-args still includes the return type:

(lldb) settings set frame-format "'${function.name-with-args}'\n"
(lldb) bt
* thread #1, stop reason = breakpoint 1.1
  * 'void __cdecl fn0(void)'
    'void __cdecl fn1(void)'
    'main'
    'static int __scrt_common_main_seh()'
    'mainCRTStartup(__formal=<unavailable>)'
    'BaseThreadInitThunk'
    'RtlUserThreadStart'

function.name-without-args also does not work:

(lldb) settings set frame-format "'${function.name-without-args}'\n"
(lldb) bt
* thread #1, stop reason = breakpoint 1.1
  * 'void __cdecl fn0(void)'
    'void __cdecl fn1(void)'
    'main'
    'static int __scrt_common_main_seh()'
    'mainCRTStartup'
    'BaseThreadInitThunk'
    'RtlUserThreadStart'

That was with PDB debug info, I tried DWARF too but the only difference was that we got some extra functions before main that are unrecognised, and the calling convention goes away:

(lldb) settings set frame-format "'${function.name}'\n"
(lldb) bt
* thread #1, stop reason = breakpoint 1.1
  * 'void fn0(void)'
    'void fn1(void)'
    'main'
  frame #3: 0x00007ff6955721a0 test.exe`test.exe[0x00000001400021a0]
  frame #4: 0x00007ff69557225c test.exe`test.exe[0x000000014000225c]
    'BaseThreadInitThunk'
    'RtlUserThreadStart'

The basic problem here is that on Windows we think name is <return type> <calling convention> <actual name>(<parameters>).

It doesn't seem like a thing that would be decided by the platform, but it looks like it is because it happens for DWARF and PDB.

[llvmbot]

@llvm/issue-subscribers-lldb

Author: David Spickett (DavidSpickett)

Found while fixing https://github.com//pull/142952, but really this has been going on for a while.

function.name and function.name-without-args don't work on Windows because it thinks that the function's "name" is like void fn(void).

For example:

C:\Users\tcwg>cat test.cpp
void fn0() {}
void fn1() { fn0();}
int main() { fn1(); return 0; }

This is the default backtrace:

lldb.exe test.exe
(lldb) target create "test.exe"
Current executable set to 'C:\Users\tcwg\test.exe' (aarch64).
(lldb) b fn0
Breakpoint 1: where = test.exe`void __cdecl fn0(void) at test.cpp:1, address = 0x00000001400148c0
(lldb) run
Process 5632 launched: 'C:\Users\tcwg\test.exe' (aarch64)
Process 5632 stopped
* thread #<!-- -->1, stop reason = breakpoint 1.1
    frame #<!-- -->0: 0x00007ff6483248c0 test.exe`void __cdecl fn0(void) at test.cpp:1
-&gt; 1    void fn0() {}
   2    void fn1() { fn0();}
   3    int main() { fn1(); return 0; }
   4
(lldb) bt
* thread #<!-- -->1, stop reason = breakpoint 1.1
  * frame #<!-- -->0: 0x00007ff6483248c0 test.exe`void __cdecl fn0(void) at test.cpp:1
    frame #<!-- -->1: 0x00007ff6483248d4 test.exe`void __cdecl fn1(void) at test.cpp:2
    frame #<!-- -->2: 0x00007ff6483248ec test.exe`main at test.cpp:3
    frame #<!-- -->3: 0x00007ff648324838 test.exe`static int __scrt_common_main_seh() at exe_common.inl:288
    frame #<!-- -->4: 0x00007ff648324d3c test.exe`mainCRTStartup(__formal=&lt;unavailable&gt;) at exe_main.cpp:16
    frame #<!-- -->5: 0x00007ff9efe52310 kernel32.dll`BaseThreadInitThunk + 48
    frame #<!-- -->6: 0x00007ff9f3a15aec ntdll.dll`RtlUserThreadStart + 60

Note that some functions lack arguments, I don't know why.

function.name does not remove the return type or parameters for some functions:

(lldb) settings set frame-format "'${function.name}'\n"
(lldb) bt
* thread #<!-- -->1, stop reason = breakpoint 1.1
  * 'void __cdecl fn0(void)'
    'void __cdecl fn1(void)'
    'main'
    'static int __scrt_common_main_seh()'
    'mainCRTStartup'
    'BaseThreadInitThunk'
    'RtlUserThreadStart'

function.mangled-name works:

(lldb) settings set frame-format "'${function.mangled-name}'\n"
(lldb) bt
* thread #<!-- -->1, stop reason = breakpoint 1.1
  * '?fn0@@<!-- -->YAXXZ'
    '?fn1@@<!-- -->YAXXZ'
    'main'
    'static int __scrt_common_main_seh()'
    'mainCRTStartup'
    'BaseThreadInitThunk'
    'RtlUserThreadStart'

function.name-with-args still includes the return type:

(lldb) settings set frame-format "'${function.name-with-args}'\n"
(lldb) bt
* thread #<!-- -->1, stop reason = breakpoint 1.1
  * 'void __cdecl fn0(void)'
    'void __cdecl fn1(void)'
    'main'
    'static int __scrt_common_main_seh()'
    'mainCRTStartup(__formal=&lt;unavailable&gt;)'
    'BaseThreadInitThunk'
    'RtlUserThreadStart'

function.name-without-args also does not work:

(lldb) settings set frame-format "'${function.name-without-args}'\n"
(lldb) bt
* thread #<!-- -->1, stop reason = breakpoint 1.1
  * 'void __cdecl fn0(void)'
    'void __cdecl fn1(void)'
    'main'
    'static int __scrt_common_main_seh()'
    'mainCRTStartup'
    'BaseThreadInitThunk'
    'RtlUserThreadStart'

That was with PDB debug info, I tried DWARF too but the only difference was that we got some extra functions before main that are unrecognised, and the calling convention goes away:

(lldb) settings set frame-format "'${function.name}'\n"
(lldb) bt
* thread #<!-- -->1, stop reason = breakpoint 1.1
  * 'void fn0(void)'
    'void fn1(void)'
    'main'
  frame #<!-- -->3: 0x00007ff6955721a0 test.exe`test.exe[0x00000001400021a0]
  frame #<!-- -->4: 0x00007ff69557225c test.exe`test.exe[0x000000014000225c]
    'BaseThreadInitThunk'
    'RtlUserThreadStart'

The basic problem here is that on Windows we think name is <return type> <calling convention> <actual name>(<parameters>).

It doesn't seem like a thing that would be decided by the platform, but it looks like it is because it happens for DWARF and PDB.

[DavidSpickett]

This would have been caught by a few tests in https://github.com/llvm/llvm-project/tree/main/lldb/test/Shell/Settings, like https://github.com/llvm/llvm-project/blob/main/lldb/test/Shell/Settings/TestFrameFormatName.test. I tried to get that working on Windows but I think we are missing the ability to parse the debug info to even breakpoint on some of those functions.

It may have also been caught by

llvm-project/lldb/test/API/commands/settings/TestSettings.py

Line 172 in b6364ab

def test_set_frame_format(self):

if it was not disabled on Windows.

I've re-enabled it but the only reason it passes is it looks for <backtick>main. And somehow main on Windows does format correctly. Any other function, and it'll fail.

[Michael137]

Thanks for raising this! I suspect the problem is the demangling. The Itanium demangler path has ways to strip out the basename etc. We probably don't do any of that for MSVC mangling. The relevant code would be:

llvm-project/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp

Lines 112 to 134 in cb3d77d

	ConstString demangled_name = mangled.GetDemangledName();
	if (demangled_name && mangled_name_cstr && mangled_name_cstr[0]) {
	if (mangled_name_cstr[0] == '_' && mangled_name_cstr[1] == 'Z' &&
	(mangled_name_cstr[2] != 'T' && // avoid virtual table, VTT structure,
	// typeinfo structure, and typeinfo
	// mangled_name
	mangled_name_cstr[2] != 'G' && // avoid guard variables
	mangled_name_cstr[2] != 'Z')) // named local entities (if we
	// eventually handle eSymbolTypeData,
	// we will want this back)
	{
	CxxMethodName cxx_method(demangled_name);
	if (!cxx_method.GetBasename().empty()) {
	std::string shortname;
	if (!cxx_method.GetContext().empty())
	shortname = cxx_method.GetContext().str() + "::";
	shortname += cxx_method.GetBasename().str();
	return ConstString(shortname);
	}
	}
	}
	if (demangled_name)
	return demangled_name;

Note how we check the _Z prefix before we create the CxxMethodName object. There's probably other places that also need to be adjusted for MSVC mangling.

[jimingham]

I think this is properly done in the Language plugin (sounds like in the demangler but I guess CPlusPlusLanguage might also provide a "name cleaner". But this shouldn't be done higher in lldb. Only the language can know what bits of the name are relevant or what they mean.

[Nerixyz]

function.name does not remove the return type or parameters for some functions:

What's the expected output there? The docs only say "The name of the current function or symbol." Currently, getting function.name tries to call GetFunctionDisplayName, which returns false for eName so this isn't handled by the C++ plugin. Instead, GetPossiblyInlinedFunctionName gets called.

One thing I found weird was that the function name can get demangled twice with different options. I'm not sure where it gets initially demangled, but there, __cdecl gets added. Initially, the demangled representation gets set in SymbolFilePDB::GetMangledForPDBFunc, which uses the DIA SDK to demangle. In Mangled it can get demangled a second time by GetMSVCDemangledStr which avoids adding the calling convention. This is only done if the DemangledNameInfo is requested, since this isn't set when demangling the PDB. There are some options when getting the demangled/undecorated name from the PDB, but they don't fit to the format that DemangledNameInfo would expect (they return new strings, but we need substrings/ranges inside the full demangled name).

Said DemangledNameInfo isn't available for MSVC mangling, but it's possible to add this, as LLVM also builds an AST for MSVC mangling (like with Itanium mangling).

[Michael137]

What's the expected output there? The docs only say "The name of the current function or symbol." Currently, getting function.name tries to call GetFunctionDisplayName, which returns false for eName so this isn't handled by the C++ plugin

Yea I don't think this one is particularly useful. I was thinking of making it the same as eFunctionNameWithArgs, but that would've potentially been unexpected to users so I dropped it. I'd be in favour of deprecating eFunctionName. We can't remove it because .lldbinits in the wild might rely on it, but at least documenting to use either the NoArgs or WithArgs form instead. @JDevlieghere @labath thoughts on "soft removing" the eFunctionName format?

One thing I found weird was that the function name can get demangled twice with different options. I'm not sure where it gets initially demangled, but there, __cdecl gets added. Initially, the demangled representation gets set in SymbolFilePDB::GetMangledForPDBFunc, which uses the DIA SDK to demangle. In Mangled it can get demangled a second time by GetMSVCDemangledStr which avoids adding the calling convention.

Yikes, that feels weird. We're using two different demanglers? Can we settle on one or the other? We were talking about removing the non-native PDB parser (i.e., the one from DIA), so maybe we should just always use the LLVM one to align with that effort?

There are some options when getting the demangled/undecorated name from the PDB, but they don't fit to the format that DemangledNameInfo would expect (they return new strings, but we need substrings/ranges inside the full demangled name).

Yea unfortunately the ItaniumDemangler didn't have such options (yet, I think @cmtice wanted to continue that work), so we opted to add the DemangledNameInfo that tracks substrings. That also allows us to more naturally let the user control which parts of the demangled string they want to display/hide.

Said DemangledNameInfo isn't available for MSVC mangling, but it's possible to add this, as LLVM also builds an AST for MSVC mangling (like with Itanium mangling).

That would be cool.

[labath]

@JDevlieghere @labath thoughts on "soft removing" the eFunctionName format?

I don't have a problem with "soft" nor "hard" removals.