Re: [lldb-dev] LLDB not loading any debug information on windows

2019-03-13 Thread Zachary Turner via lldb-dev 
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> 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> wrote:
>
>> 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 
>>
>> >
>>
>> > int a=10;
>>
>> >
>>
>> > int main(int argc, char *argv[]){
>>
>> > for(int i=0;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
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB not loading any debug information on windows

2019-03-13 Thread Adrian McCarthy via lldb-dev 
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> wrote:

> 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 
>
> >
>
> > int a=10;
>
> >
>
> > int main(int argc, char *argv[]){
>
> > for(int i=0;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
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] DEBUG_PRINTF() macro

2019-03-13 Thread Jim Ingham via lldb-dev 
Seems like there are two kinds of DEBUG_PRINTF.  

One is in SymbolFileDWARF, DWARFASTParserClang.cpp etc, where that is inserting 
code into lldb.  Those uses seem to me like they should be going to the dwarf 
log channel when verbose is on.  Many of these places also acquire the dwarf 
log, so they could do this right.  I have no objections to switching these over 
(I'll leave it to Greg and others who debug DWARF a lot to decide whether they 
can be removed altogether.)

The other flavor of DEBUG_PRINTF isn't used in lldb code, it is inserted into 
code that we are compiling and inserting into the target.  There's a bunch of 
this in the ObjCLanguageRuntime, for instance.  When we run the function we've 
inserted it prints info about the information it is gathering.  Generally, the 
output is triggered by some log setting, which then sets an argument we pass to 
the function we're executing.

This is a really handy way to debug the work that functions we insert into the 
target are doing.  We should not remove any of those uses.  Presumably that 
wasn't what you were referring to, but just making sure they didn't get cut 
down in the same charge.

Jim


> On Mar 13, 2019, at 9:39 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Apparently we have a macro called DEBUG_PRINTF() which, if you compile LLDB 
> with a special pre-processor setting enabled, will cause certain messages to 
> be printed to stdout while running LLDB.
> 
> Does anyone use this?  This seems like a kind of hacky alternative to 
> tracepoints and/or pretty printers, and in some cases is causing otherwise 
> dead code to be compiled into the binary, so there's some benefit to removing 
> it.  
> 
> Is anyone opposed to removing all of this?
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] DEBUG_PRINTF() macro

2019-03-13 Thread Zachary Turner via lldb-dev 
Apparently we have a macro called DEBUG_PRINTF() which, if you compile LLDB
with a special pre-processor setting enabled, will cause certain messages
to be printed to stdout while running LLDB.

Does anyone use this?  This seems like a kind of hacky alternative to
tracepoints and/or pretty printers, and in some cases is causing otherwise
dead code to be compiled into the binary, so there's some benefit to
removing it.

Is anyone opposed to removing all of this?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [8.0.0 Release] Release Candidate 5 sources, docs, and binaries available

2019-03-13 Thread Hans Wennborg via lldb-dev 
Hello everyone,

Source code, docs, and (a few) binaries for LLVM-8.0.0-rc5 are now
available at https://prereleases.llvm.org/8.0.0/#rc5

More binaries will be added as they become available.

So far this looks like it will be the last release candidate before
the final tag, which will come soon, so if you find any issues, please
let me know as soon as possible by filing a bug blocking
https://llvm.org/pr40331

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Needs help contributing to lldb-vscode.

2019-03-13 Thread Pavel Labath via lldb-dev 

On 12/03/2019 20:34, Leonard Mosescu via lldb-dev wrote:

Greg, what do you think?


On Tue, Mar 12, 2019 at 11:50 AM Qianli Ma > wrote:


Hi lldb community,

I am currently working on a project related to lldb. I'd like to
write a DAP RPC server similars to lldb-vscode.cc


 but
exports I/O to internal RPC clients. Doing so requires me to reuse
some functions defined in lldb-vscode.cc

.
However as those functions are defined using forward declaration I
am not able to do that.

I'd like refactor the code a bit. More specifically, I'd like to
extract all helper functions in lldb-vscode.cc


 into
a separate file and create a header for it.  BTW, IMO it's good to
make this lldb-vscode more general so that it can be used by other
debugger frontends besides vscode.

Please let me know WDYT and how I can proceed to submit changes for
review.

Thanks and Regards
Qianli




The way I understand this idea, you want to make (parts of) lldb-vscode 
a library. The way this is usually done in llvm is that you put all of 
the library stuff in a separate folder, with its own headers, cmake 
target and everything. Then, you can make lldb-vscode executable (or 
whatever its called) link against that library. Your downstream tool can 
do the same.


I think doing that is a good idea. The only part we need to figure out 
is where to put the new library code. Normally, all our library-ized 
code lives under source/, but this library would be special in that it 
sits on top of the SB api rather than beneath it. So, even though it 
sounds a weird to have a library living under tools/, it might be better 
to have the new library be there instead of under source/.


regards,
pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev