(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.

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary 
Turner via lldb-dev
Sent: Wednesday, March 13, 2019 8:07 PM
To: Adrian McCarthy
Subject: Re: [lldb-dev] LLDB not loading any debug information on windows

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".

On Wed, Mar 13, 2019 at 5:01 PM Adrian McCarthy via lldb-dev 
<lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>> wrote:
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.

On Mon, Mar 4, 2019 at 11:00 AM Christoph Baumann via lldb-dev 
<lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>> wrote:
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 
> -DLLDB_PYTHON_HOME=“C:\program files\python37“ -DLLVM_BUILD_TESTS=0 
> -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<http://llvm.org>, same result.

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

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


lldb-dev mailing list
lldb-dev mailing list
lldb-dev mailing list

Reply via email to