LLDB not loading any debug information on windows

Subprojects LLDB
1

Hey,

in order to try lldb on windows, i built (with clang compiler and lld linker (v7.0.1)) llvm, clang, lld and of course lldb from latest source with the following command line:

cmake -G Ninja -DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl -DCMAKE_LINKER=lld-link -DLLDB_RELOCATABLE_PYTHON=1 -DLLDB_PYTHON_HOME=“C:\program files\python37“ -DLLVM_BUILD_TESTS=0 -DLLVM_BUILD_BENCHMARKS=0 -DLLVM_BUILD_EXAMPLES=0 -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGET_ARCH=host -DCMAKE_INSTALL_PREFIX=“…\release“ …\src\llvm

ninja install

Here my little program i used to test lldb:

//main.c

#include <stdio.h>

int a=10;

int main(int argc, char *argv){

for(int i=0;i<argc;i++){

printf(“%s\n”, argv[i]);

}

return(0);

}

I compiled the above with „clang main.c -glldb -o a.exe“, which generated the executable a.exe and corresponding debug information a.pdb.

I launched lldb with „lldb a.exe“ and tried to load the debug information with „target symbols add a.pdb“, however this resulted in „error: symbol file [….]\a.pdb does not match any existing module“.

I am using Windows 10 pro 64bit, my both, my test program and lldb were compiled for x64 target.

I have also tried the prebuilt llvm/lldb binaries (v8.0.0, v7.0.1) found on llvm.org, same result.

I feel like i am missing something (unless lldb just does not work on windows yet).

(On a sidenote, compiling with -gdwarf-5 makes clang crash. I can send the debug information clang spits out once my debug build finishes.)

Greetings

2

Sorry for the delay. There’s definitely something going wrong here.

If you specify the .pdb file (target symbols add a.pdb), it iterates through the objfile plugins to see if any match, and none of them do (because a PDB file is not a “module”).

If you specify the .exe file (target symbols add a.exe), it matches an objfile plugin and creates the symbol vendor, but the symbol vendor says the symbol file is the .exe itself rather than the .pdb, so it appears to work but no symbols are actually loaded.

If you specify the .exe with -s (target symbols add -s a.exe), you again get silent failure as in the previous case.

I’ll look at this some more tomorrow to see if I can figure out what this code path is supposed to be doing.

3

Two things stand out to me as odd here.

  1. -glldb. -g is supposed to specify the debug information format, either dwarf, codeview, or whichever is the default. I’ve never heard of anyone using -glldb (or for that matter -ggdb). Just -g, -gcodeview, or -gdwarf.

  2. You’re using clang instead of clang-cl. While it’s possible to make things work, we designed clang-cl specifically to avoid these kinds of issues, so I would first try running clang-cl /Z7 main.c and see if things suddenly start working better.

To be honest, I’m surprised it’s even generating a PDB at all with the given command line, but then again it’s not a codepath anyone has really tested, so maybe it’s generating “something”.

4

(Resend, remembering to add lldb-dev back this time)

Asking for DWARF on Windows generally doesn’t get you any info at all.

FTR, the -glldb option means generate DWARF, “tuned” for LLDB. Clang understands three “debugger tunings” which are gdb, lldb, and sce. The distinctions are minor and not relevant here.

–paulr

5

You actually can get dwarf on Windows, i made this work a long time ago before we were able to generate PDB, while i was still porting lldb to Windows. Since pdb wasn’t a thing at the time, dwarf was necessary in order to get anything working.

I don’t know what the state of it is today though and I’d definitely consider it unsupported at minimum