On Windows the function does not have a symbol associated with it:
Function: id = {0x000001c9}, name = "_Dfunction", range =
[0x0000000140001000-0x0000000140001004)
LineEntry: <...>
Whereas it does on Linux:
Function: id = {0x00000023}, name = "_Dfunction", range =
[0x0000000000000734-0x0000000000000738)
LineEntry: <...>
Symbol: id = {0x00000058}, range =
[0x0000000000000734-0x0000000000000738), name="_Dfunction"
This means that frame.symbol is not valid on Windows.
However, frame.function is valid and it also has a "mangled" attribute.
So I've updated the test to check the symbol if we've got it, and the
function always.
In both cases we check that mangled is empty (meaning it has not been
treated as mangled) and that the display name matches the original
symbol name.
25 lines
910 B
Python
25 lines
910 B
Python
import lldbsuite.test.lldbutil as lldbutil
|
|
from lldbsuite.test.lldbtest import *
|
|
|
|
|
|
class TestCase(TestBase):
|
|
def test_functions_having_dlang_mangling_prefix(self):
|
|
"""
|
|
Ensure C functions with a '_D' prefix alone are not mistakenly treated
|
|
as a Dlang mangled name. A proper Dlang mangling will have digits
|
|
immediately following the '_D' prefix.
|
|
"""
|
|
self.build()
|
|
_, _, thread, _ = lldbutil.run_to_name_breakpoint(self, "_Dfunction")
|
|
frame = thread.frame[0]
|
|
|
|
symbol = frame.symbol
|
|
# On Windows the function does not have an associated symbol.
|
|
if symbol.IsValid():
|
|
self.assertFalse(symbol.mangled)
|
|
self.assertEqual(symbol.GetDisplayName(), "_Dfunction")
|
|
|
|
function = frame.function
|
|
self.assertFalse(function.mangled)
|
|
self.assertEqual(function.GetDisplayName(), "_Dfunction")
|