Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

Setting Breakpoints Dependent on Microsoft Compiler Environment #45128

Open Quuxplusone opened 4 years ago

Quuxplusone commented 4 years ago
Bugzilla Link PR46158
Status NEW
Importance P normal
Reported by Jussi Jumppanen (info@zeusedit.com)
Reported on 2020-06-01 08:23:40 -0700
Last modified on 2020-08-06 17:31:14 -0700
Version 10.0
Hardware PC Windows 2000
CC clayborg@gmail.com, compnerd@compnerd.org, crr0004@gmail.com, jdevlieghere@apple.com, llvm-bugs@lists.llvm.org, stilis@microsoft.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also
This is more of a question than a bug report.

In playing with LLDB on a Windows 10 I struggled to get the breakpoints to work.

Eventually I stumbled across the cause of the issue, which is described in the
steps below:

1. Open command line prompt:

    Microsoft Windows [Version 10.0.18363.836]
    (c) 2019 Microsoft Corporation. All rights reserved.

2. Run LLDB on a debug 'test.exe' but as shown below the breakpoints fail to
set:

    C:\Tutorial\c++>lldb.exe test.exe
    (lldb) target create "test.exe"
    Current executable set to 'C:\Tutorial\c++\test.exe' (i686).
    (lldb) b 7
    error: No selected frame to use to find the default file.
    error: No file supplied and no default file available.
    (lldb) exit

3. The command prompt used was not configured to run the Microsoft compiler:

    C:\Tutorial\c++>cl.exe
    'cl.exe' is not recognized as an internal or external command, operable program or batch file.

4. I then setup the command prompt to run the Microsoft compiler using their
standard batch file:

    C:\Tutorial\c++>"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\VsDevCmd.bat"
    **********************************************************************
    ** Visual Studio 2019 Developer Command Prompt v16.6.0
    ** Copyright (c) 2020 Microsoft Corporation
    **********************************************************************

5. With the command prompt configured for the Microsoft compiler:

    C:\Tutorial\c++>cl.exe
    Microsoft (R) C/C++ Optimizing Compiler Version 19.26.28805 for x86
    Copyright (C) Microsoft Corporation.  All rights reserved.

6. Now the LLDB breakpoints work as expected:

    C:\Tutorial\c++>lldb.exe test.exe
    (lldb) target create "test.exe"
    Current executable set to 'C:\Tutorial\c++\test.exe' (i686).
    (lldb) b 7
    Breakpoint 1: where = test.exe`_main + 87 at test.cpp:7, address = 0x0040b527
    (lldb) exit

So it seems the LLDB is somehow dependent of the Microsoft compiler environment
setup. Is this correct?

If so what is the actual dependency?

Cheers Jussi
Quuxplusone commented 4 years ago
It might depend on the version of lldb.exe that you are using. Did you build
this from top of tree? Download it from somewhere? Get it from a package?

The reason I ask is that older version of LLDB was able to parse PDB files only
by using the PDB DLL from a windows install. This might be something that is
detected only after running the microsoft compiler setup scripts.

Newer versions of LLDB can parse PDB files using an internal plug-in. Not sure
if this is always used in newer LLDB releases, or if there is a setting to
switch between the two.

In LLDB there are two plugins:
lldb/source/Plugins/SymbolFile/PDB
lldb/source/Plugins/SymbolFile/NativePDB

SymbolFilePDB seems to control it all and it determines if it should use the
native PDB reader by this function:

static bool ShouldUseNativeReader() {
#if defined(_WIN32)
  llvm::StringRef use_native = ::getenv("LLDB_USE_NATIVE_PDB_READER");
  return use_native.equals_lower("on") || use_native.equals_lower("yes") ||
         use_native.equals_lower("1") || use_native.equals_lower("true");
#else
  return true;
#endif
}

So if you are using the latest sources I would expect this to work out of the
box. If you are using an older LLDB it may depend on being able to locate the
native PDB DLL on the windows install.

Let us know what your LLDB version is and we will know how to proceed after
that.
Quuxplusone commented 4 years ago
> Did you build this from top of tree? Download it from somewhere? Get it from
a package?

I downloaded the clang 10 Windows (32-bit) installer from the clang down page:

    https://releases.llvm.org/download.html

And to get the debugger to run I added in the Python 3.6.10 binaries from the
Python page:

    https://www.python.org/downloads/windows/

This is the LLDB version:

    c:>lldb.exe --version
    lldb version 10.0.0

> The reason I ask is that older version of LLDB was able to parse PDB files
only by using the PDB DLL from a windows install.

That does makes sense as when I build the test.exe I can see a test.pdb file is
created.

> This might be something that is detected only after running the microsoft
compiler setup scripts.

Since the Microsoft script changes the PATH environment variable this would
then allow the debugger to find that PDB DLL file.

So that too makes a lot of sense.

> Newer versions of LLDB can parse PDB files using an internal plug-in.

I am pretty sure what you have described is the cause of the issue.

I'll have a go at building the debugger from source and getting the plug-in to
work.

Thanks for this feedback.

Cheers Jussi
Quuxplusone commented 4 years ago
Just for the sake of completeness I tried using the environment variable with
the version 10.0 of the LLDB that I have installed, but that did not work:

   C:\Tutorial\c++>set LLDB_USE_NATIVE_PDB_READER=1

   C:\Tutorial\c++>set LLDB_USE_NATIVE_PDB_READER
   LLDB_USE_NATIVE_PDB_READER=1

   C:\Tutorial\c++>lldb test.exe
   (lldb) target create "test.exe"
   Current executable set to 'C:\Tutorial\c++\test.exe' (i686).
   (lldb) b 7
   error: No selected frame to use to find the default file.
   error: No file supplied and no default file available.
   (lldb)exit

Cheers Jussi
Quuxplusone commented 4 years ago

can you attach the test.exe and test.pdb? I can see if breakpoints work on a local copy of LLDB that isn't on windows. I thought we had a functional PDB plug-in that didn't require the DLL.

Quuxplusone commented 4 years ago

Might also be worth checking the blame list on the SymbolFilePDB and SymbolFileNativePDB plug-ins and include them on this bug. I didn't do any of the PDB work, but others that have can offer better guidance.

Quuxplusone commented 4 years ago
> can you attach the test.exe and test.pdb?

In trying to attaching the files I got this error message:

    The file you are trying to attach is 2817 kilobytes (KB) in size. Attachments cannot be more than 1000 KB.

So instead I have upload the files to here:

    http://www.zeusedit.com/z300/test.zip

That 2.8 meg file contains the exe, pdb and source file used in my test.

The exe would have been built using this command:

    clang++ test.cpp -Wall -g -o test.exe

Cheers Jussi
Quuxplusone commented 4 years ago

This confused me a lot when I was trying to debug an exe, so I dug into the source code.

I have built LLVM, Clang and LLDB against commit ef32c611aa214dea855364efd7ba451ec5ec3f74 using MSVC and Ninja and it does work when you specify the environment variable LLDB_USE_NATIVE_PDB_READER="TRUE".

It took me awhile to realise the PDB plugin does a lazy load of the DLL and does seem to throw an error out, however I couldn't see where this error is actually being swallowed, maybe by llvm::consumeError? The error is generated in llvm\lib\DebugInfo\PDB\DIA\DIASession.cpp#LoadDIA

For anyone else's reference, the dll being loaded is msdia140.dll.