[Bug 22177] New: LLDB expression evaluator does not demangle C++ names on Windows

Bug ID 22177
Summary LLDB expression evaluator does not demangle C++ names on Windows
Product lldb
Version unspecified
Hardware PC
OS Windows NT
Status NEW
Severity normal
Priority P
Component All Bugs
Assignee lldb-dev@cs.uiuc.edu
Reporter ted.woodward@codeaurora.org
Classification Unclassified

Created attachment 13656 [details]
testcase

Build the attached file. Note that I had to build it on Linux because clang on
Windows didn't produce a native executable with symbols that LLDB could read.

clang -g expr_test.cpp -o expr_test.elf

Run Windows LLDB on expr_test.elf, and run these commands:

p main
p foo
p _Z3fooi

With Windows LLDB I see:
(lldb) p main
(int (*)()) $0 = 0x00000000004004f0
(lldb) p foo
error: use of undeclared identifier 'foo'
error: 1 errors parsing expression
(lldb) p _Z3fooi
(int (*)(int)) $1 = 0x00000000004004d0

With Linux LLDB I see:
(lldb) p main
(int (*)()) $0 = 0x00000000004004f0
(lldb) p foo
(int (*)(int)) $1 = 0x00000000004004d0
(lldb) p _Z3fooi
(int (*)(int)) $2 = 0x00000000004004d0

Windows LLDB is not correctly demangling _Z3fooi and resolving that as foo.

Zachary Turner changed bug 22177

What Removed Added
CC david.majnemer@gmail.com, llvmbugs@cs.uiuc.edu
Component All Bugs All Bugs
Assignee lldb-dev@cs.uiuc.edu unassignedbugs@nondot.org
Product lldb lld
Summary LLDB expression evaluator does not demangle C++ names on Windows LLD does not generate a symbol table on Windows

Comment # 2 on bug 22177 from Zachary Turner

So the problem is not that it can't demangle names.  In fact, it can demangle
names just fine.  You can see it demangling main.  And if you change the
signature of main in expr_test.cpp to int main(int, char**) then you will get
this from LLDB (note that I'm using a PE file here, generated with
-fuse-ld=lld):

d:\testexe>d:\src\llvm\build\ninja\bin\lldb
(lldb) file expr_test.exe
Current executable set to 'expr_test.exe' (i386).
(lldb) p main
(int (*)(int, char **)) $0 = 0x00415020

But it still can't handle foo even LLD's debug info.  The problem seems to be
that LLD isn't building the symbol table correctly.

d:\testexe>d:\src\llvm\build\ninja\bin\llvm-readobj.exe --symbols expr_test.exe

File: expr_test.exe
Format: COFF-i386
Arch: i386
AddressSize: 32bit
Symbols [
]

I don't know what I'm supposed to see here, but I would expect to see "main"
and "foo" in that list in some form or another.

I guess it just happens to be finding main because it's the entry point, so we
got lucky.  This sounds like an issue for someone who works on LLD.