Re: [lldb-dev] Need help with failing LLDB tests on Windows

[Adrian McCarthy via lldb-dev]

FYI:  The problem was the SWIG bug that becomes critical when combined with
Python 3.7+.  Updating SWIG to 4.0.2 resolved all of the test failures.

I'm not sure why this wasn't consistently a problem before, though, since I
was already using this combination of versions for a while before the tests
started failing.

There's actually a Cmake warning about the version incompatibility.  I'm
going to propose that this warning be upgraded to an error.

Thanks everyone!

On Tue, Nov 10, 2020 at 3:06 PM Tatyana Krasnukha <
tatyana.krasnu...@synopsys.com> wrote:

> On Windows one should run debug version of Python (python_d.exe) to load
> debug version of liblldb.dll. I hope this will help you.
>
>
>
> *From:* lldb-dev  *On Behalf Of *Adrian
> McCarthy via lldb-dev
> *Sent:* Tuesday, November 10, 2020 4:00 AM
> *To:* Ted Woodward 
> *Cc:* LLDB 
> *Subject:* Re: [lldb-dev] Need help with failing LLDB tests on Windows
>
>
>
> Thanks for all the info and pointers.  That's helping me zero in on the
> problem.
>
>
>
> This category of the failures appears to all be dotest.py tests, so it
> makes sense that it's the second import statement (per Pavel's explanation).
>
>
>
> The module is not being found because it's actually named _lldb_d.pyd.
> Apparently the `_d` suffix is because I'm building debug.  That seems
> consistent with Stella's experience.
>
>
>
> However, I've been building debug since before these problems arose.  (In
> fact, I've been working on fixes for a small number of tests that only fail
> in debug, because of an assertion that detects the problem.)
>
>
>
> Ted's got me thinking that it was working due to a symlink that somehow
> got blown away and/or isn't being recreated by the build.  If I recall
> correctly, the symlinks on Windows are created using ln.exe, which may come
> from GnuWin32 or from git/usr/bin.  In my case, it's git/usr/bin.  There
> seem to have been many git updates in the past couple months, so perhaps
> one of those updates tweaked ln.exe.  That could have been the trigger for
> me.  Folks who didn't take the git update or who are configured to prefer
> GnuWin32 tools might not have been affected.
>
>
>
> I'll let you know what I eventually find.
>
>
>
> On Wed, Nov 4, 2020 at 12:05 PM Ted Woodward  wrote:
>
> To expand a bit on what Pavel has written, the lldb module should be in
> \lib\site-packages\lldb . In that directory is a file, _lldb.pyd,
> that should be a copy of \bin\liblldb.dll .
>
> Do both files exist? Is _lldb.pyd a copy of liblldb.dll?
> See function create_relative_symlink in llvm-project/lldb/CMakeLists.txt
> for the copy (on non-unix hosts) procedure.
>
> Did you recently change your version of swig? LLDB requires swig 2, but,
> as you pointed out last year, there are issues with some versions of swig.
> We use 4.0.1 on Windows.
>
> > -Original Message-
> > From: lldb-dev  On Behalf Of Pavel
> Labath
> > via lldb-dev
> > Sent: Wednesday, November 4, 2020 2:49 AM
> > To: Adrian McCarthy ; LLDB  > d...@lists.llvm.org>
> > Subject: [EXT] Re: [lldb-dev] Need help with failing LLDB tests on
> Windows
> >
> > On 04/11/2020 01:53, Adrian McCarthy via lldb-dev wrote:
> > > For the past couple weeks, I've been trying to figure out why
> > > approximately 900+ LLDB tests have been failing for me on my local
> > > Windows builds.  Bisect turned up nothing--the "good" version that was
> > > working for me no longer works.  Since nobody else seems to be seeing
> > > these failures, I suspect it's something environmental.
> > >
> > > There are three categories of errors.  I'm currently focused on
> > > failures that look like this:
> > >
> > > FAIL: lldb-api :: lang/objc/unicode-string/TestUnicodeString.py
> (732
> > > of 2180)
> > >  TEST 'lldb-api ::
> > > lang/objc/unicode-string/TestUnicodeString.py' FAILED
> > > 
> > > Script:
> > > --
> > > C:/Program Files/Python38/python.exe
> > > D:/src/llvm/llvm-project/lldb\test\API\dotest.py -S nm -u CXXFLAGS
> > > -u CFLAGS --enable-crash-dialog --env
> > > LLVM_LIBS_DIR=D:/src/llvm/build/ninja_dbg/./lib --arch x86_64
> > > --build-dir D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex -s
> > > D:/src/llvm/build/ninja_dbg/lldb-test-traces
> --lldb-module-cache-dir
> > > D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-
&g

Re: [lldb-dev] Need help with failing LLDB tests on Windows

[Adrian McCarthy via lldb-dev]

Thanks for all the info and pointers.  That's helping me zero in on the
problem.

This category of the failures appears to all be dotest.py tests, so it
makes sense that it's the second import statement (per Pavel's explanation).

The module is not being found because it's actually named _lldb_d.pyd.
Apparently the `_d` suffix is because I'm building debug.  That seems
consistent with Stella's experience.

However, I've been building debug since before these problems arose.  (In
fact, I've been working on fixes for a small number of tests that only fail
in debug, because of an assertion that detects the problem.)

Ted's got me thinking that it was working due to a symlink that somehow got
blown away and/or isn't being recreated by the build.  If I recall
correctly, the symlinks on Windows are created using ln.exe, which may come
from GnuWin32 or from git/usr/bin.  In my case, it's git/usr/bin.  There
seem to have been many git updates in the past couple months, so perhaps
one of those updates tweaked ln.exe.  That could have been the trigger for
me.  Folks who didn't take the git update or who are configured to prefer
GnuWin32 tools might not have been affected.

I'll let you know what I eventually find.

On Wed, Nov 4, 2020 at 12:05 PM Ted Woodward  wrote:

> To expand a bit on what Pavel has written, the lldb module should be in
> \lib\site-packages\lldb . In that directory is a file, _lldb.pyd,
> that should be a copy of \bin\liblldb.dll .
>
> Do both files exist? Is _lldb.pyd a copy of liblldb.dll?
> See function create_relative_symlink in llvm-project/lldb/CMakeLists.txt
> for the copy (on non-unix hosts) procedure.
>
> Did you recently change your version of swig? LLDB requires swig 2, but,
> as you pointed out last year, there are issues with some versions of swig.
> We use 4.0.1 on Windows.
>
> > -Original Message-
> > From: lldb-dev  On Behalf Of Pavel
> Labath
> > via lldb-dev
> > Sent: Wednesday, November 4, 2020 2:49 AM
> > To: Adrian McCarthy ; LLDB  > d...@lists.llvm.org>
> > Subject: [EXT] Re: [lldb-dev] Need help with failing LLDB tests on
> Windows
> >
> > On 04/11/2020 01:53, Adrian McCarthy via lldb-dev wrote:
> > > For the past couple weeks, I've been trying to figure out why
> > > approximately 900+ LLDB tests have been failing for me on my local
> > > Windows builds.  Bisect turned up nothing--the "good" version that was
> > > working for me no longer works.  Since nobody else seems to be seeing
> > > these failures, I suspect it's something environmental.
> > >
> > > There are three categories of errors.  I'm currently focused on
> > > failures that look like this:
> > >
> > > FAIL: lldb-api :: lang/objc/unicode-string/TestUnicodeString.py
> (732
> > > of 2180)
> > >  TEST 'lldb-api ::
> > > lang/objc/unicode-string/TestUnicodeString.py' FAILED
> > > 
> > > Script:
> > > --
> > > C:/Program Files/Python38/python.exe
> > > D:/src/llvm/llvm-project/lldb\test\API\dotest.py -S nm -u CXXFLAGS
> > > -u CFLAGS --enable-crash-dialog --env
> > > LLVM_LIBS_DIR=D:/src/llvm/build/ninja_dbg/./lib --arch x86_64
> > > --build-dir D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex -s
> > > D:/src/llvm/build/ninja_dbg/lldb-test-traces
> --lldb-module-cache-dir
> > > D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-
> > lldb\lldb-api
> > > --clang-module-cache-dir
> > > D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-
> > clang\lldb-api
> > > --executable D:/src/llvm/build/ninja_dbg/./bin/lldb.exe --compiler
> > > D:/src/llvm/build/ninja_dbg/bin/clang.exe --dsymutil
> > > D:/src/llvm/build/ninja_dbg/./bin/dsymutil.exe --filecheck
> > > D:/src/llvm/build/ninja_dbg/./bin/FileCheck.exe --yaml2obj
> > > D:/src/llvm/build/ninja_dbg/./bin/yaml2obj.exe --lldb-libs-dir
> > > D:/src/llvm/build/ninja_dbg/./lib
> > > D:\src\llvm\llvm-project\lldb\test\API\lang\objc\unicode-string -p
> > > TestUnicodeString.py
> > > --
> > > Exit Code: 1
> > >
> > > Command Output (stdout):
> > > --
> > > lldb version 12.0.0 (https://github.com/llvm/llvm-project.git
> > > <https://github.com/llvm/llvm-project.git> revision
> > > 0fdcd1ae1c988fa19d0c97e9e8678b93a0da)
> > >clang revision 0fdcd1ae1c988fa19d0c97e9e8678b

[lldb-dev] Need help with failing LLDB tests on Windows

[Adrian McCarthy via lldb-dev]

For the past couple weeks, I've been trying to figure out why approximately
900+ LLDB tests have been failing for me on my local Windows builds.
Bisect turned up nothing--the "good" version that was working for me no
longer works.  Since nobody else seems to be seeing these failures, I
suspect it's something environmental.

There are three categories of errors.  I'm currently focused on failures
that look like this:

FAIL: lldb-api :: lang/objc/unicode-string/TestUnicodeString.py (732 of
> 2180)
>  TEST 'lldb-api ::
> lang/objc/unicode-string/TestUnicodeString.py' FAILED 
> Script:
> --
> C:/Program Files/Python38/python.exe
> D:/src/llvm/llvm-project/lldb\test\API\dotest.py -S nm -u CXXFLAGS -u
> CFLAGS --enable-crash-dialog --env
> LLVM_LIBS_DIR=D:/src/llvm/build/ninja_dbg/./lib --arch x86_64 --build-dir
> D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex -s
> D:/src/llvm/build/ninja_dbg/lldb-test-traces --lldb-module-cache-dir
> D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-lldb\lldb-api
> --clang-module-cache-dir
> D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-clang\lldb-api
> --executable D:/src/llvm/build/ninja_dbg/./bin/lldb.exe --compiler
> D:/src/llvm/build/ninja_dbg/bin/clang.exe --dsymutil
> D:/src/llvm/build/ninja_dbg/./bin/dsymutil.exe --filecheck
> D:/src/llvm/build/ninja_dbg/./bin/FileCheck.exe --yaml2obj
> D:/src/llvm/build/ninja_dbg/./bin/yaml2obj.exe --lldb-libs-dir
> D:/src/llvm/build/ninja_dbg/./lib
> D:\src\llvm\llvm-project\lldb\test\API\lang\objc\unicode-string -p
> TestUnicodeString.py
> --
> Exit Code: 1
>
> Command Output (stdout):
> --
> lldb version 12.0.0 (https://github.com/llvm/llvm-project.git revision
> 0fdcd1ae1c988fa19d0c97e9e8678b93a0da)
>   clang revision 0fdcd1ae1c988fa19d0c97e9e8678b93a0da
>   llvm revision 0fdcd1ae1c988fa19d0c97e9e8678b93a0da
>
> --
> Command Output (stderr):
> --
> Traceback (most recent call last):
>   File "D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb\__init__.py",
> line 35, in 
> import _lldb
> ModuleNotFoundError: No module named '_lldb'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "D:/src/llvm/llvm-project/lldb\test\API\dotest.py", line 7, in
> 
> lldbsuite.test.run_suite()
>   File
> "D:\src\llvm\llvm-project\lldb\packages\Python\lldbsuite\test\dotest.py",
> line 874, in run_suite
> import lldb
>   File "D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb\__init__.py",
> line 38, in 
> from . import _lldb
> ImportError: cannot import name '_lldb' from partially initialized module
> 'lldb' (most likely due to a circular import)
> (D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb\__init__.py)


It looks like the code in question is generated by Swig (so perhaps it
depends on the version of Swig?).  The relevant bit seems to be:

try:
> # Try an absolute import first.  If we're being loaded from lldb,
> # _lldb should be a built-in module.
> import _lldb
> except ImportError:
> # Relative import should work if we are being loaded by Python.
> from . import _lldb


I don't have much background in Python modules or how Swig produces the
bindings.  It seems suspicious to me that both import attempts are failing
(and that we need two).  I'm hoping someone can offer some clues about
what's going on here and how it's supposed to work.  Is the hint about an
import cycle relevant or a red herring?

Python 3.8.2
Swig 3.0.12

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

Re: [lldb-dev] lldb10 can not hit break point on windows platform

[Adrian McCarthy via lldb-dev]

On Windows, LLVM is migrating to its own debug info reading code (the
Native PDB reader) instead of relying on DIA (a Microsoft-provided
Windows-only DLL for accessing debug info), so that might explain the
difference between the older versions and the current.

I don't know enough about LLDB's model to understand how debug info for
run-time generated code is handled.  Certainly, at the time your transcript
shows trying to set the breakpoint, the TestFunction.cpp code hasn't yet
been compiled, so it's not a surprise that it cannot resolve the breakpoint
at that time.  When TestFunction.cpp gets JITted into code, LLDB would have
to (1) be informed of the new code, (2) locate the debug info, and (3) try
again to resolve the pending breakpoint.  For me, there are a lot of
unknowns in that sequence, so I cannot say whether it's expected to work in
the current version.  If the JITted code is "loaded" dynamically the same
way a DLL can be, then step 1 should work.  But if the JIT code is brought
into process memory some other way, then I think it's likely the Windows
debugger isn't getting notified and thus cannot do steps 2 and 3.

Is it possible to reduce the problem down to a minimal sample program that
reproduces the problem and to include it in a bug report?

Thanks,
Adrian.



On Sat, Oct 17, 2020 at 1:51 AM le wang via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hello,everyone:
>   I have a problem when download llvm10.0.1 and use lldb to debug my
> process on windows10 x64 platform. but with no debug point hit.
> the command is
> （lldb）target create "D:/code/MLExecuteTest.exe"
> Current executable set to 'D:/code/MLExecuteTest.exe'  (x86_64)
> （lldb）br s -fE:/test/TestFunction.cpp -l1
> Breakpoint 1: no locations(pending).
> WARNING :  Unable to resolve breakpoint to any actual locations.
> （lldb）r
> Process 16228 launched 'D:/code/MLExecuteTest.exe'
> Process 16228 exited with status = 1(0x0001)
> my using detail is  this below:
> MLExecuteTest.exe is my process which will first compile the script
>  TestFunction.cpp on debug mode  and generate binary code in its memory, of
> course binary code has debug information, and then  it use JIT
> ExecuteEngine to execute the binary code. I want to know, is llvm 10.0.1
> support this using on windows platform. since before we use llvm5.0 on
> windows platform is OK, breakpoints can be hit. but while update version to
> 10.0.1, with same operation ,breakpoints can not be hit. so is llvm10.0.1
> support or has any changes on this using on windows platform?
>
> Thanks,
> le wang
> ___
> 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 build searching for the wrong Python, again.

[Adrian McCarthy via lldb-dev]

I've figured out some of the *what* but I still don't understand the *why*.

I checked the Windows registry, and found some remnants referencing Python
3.6.  I doubt that's related, but I obliterated them anyway.

I scrutinized the very noisy output of Cmake and discovered two things:

1.  Cmake found my Python 3.8, right where it should be, then it said,
"Could NOT find Python3 (missing: Development)".  I'm not sure why it
didn't think that version has the development files--it does.
2.  Next, Cmake found Python 3.7 buried in the Visual Studio 2019
installation tree.  (I keep forgetting that VS smuggles other software onto
the machine.)  I have no idea HOW Cmake found this version.  It's not
anywhere in the PATH.  It's not referenced by any other environment
variables.  If it's referenced from the Windows registry, I couldn't find
it.  It's just magic, I guess.

So I spun up the Visual Studio Installer and removed every package that
mentioned Python.  I then trashed my build tree and started again.

This time, Cmake selected my Python 3.8 tree, apparently satisfied that it
does indeed have the development files.  (Why does the presence of an
unreferenced Python 3.7 cause Cmake to think the easy-to-find 3.8
installation doesn't have development files???  Sounds like a Cmake bug to
me.)

So, for the moment, I have a working build again.

It's interesting to note that, in the four or five times since last fall
that I've been bit by the wrong-version-of-Python-while-building-LLDB bug,
the "solution" has been different.  I wonder what it'll be next time.

Thanks to the folks who sent me advice off-list.

Adrian.

On Thu, Sep 3, 2020 at 1:42 PM Adrian McCarthy  wrote:

> After rebasing, my local LLDB builds have again broken because it goes
> looking for the wrong Python DLL.  I'm searching through git logs, but I'm
> not seeing a related change.
>
> Does anyone know what causes CMake to get confused about which Python
> versions are installed?
>
> LINK : fatal error LNK1104: *cannot open file 'python37_d.lib'*
>
> Why is it looking for 3.7?  My CMake command uses every hint I know about
> to ensure that it finds Python 3.8:
>
> cmake -GNinja -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
> -DCMAKE_BUILD_TYPE=Debug -DLLDB_TEST_DEBUG_TEST_CRASHES=1
> -DPYTHON_HOME="C:\Program Files\Python*38*"
> -DLLDB_PYTHON_HOME="C:\Program Files\Python*38*"
> -DPython3_ROOT_DIR="C:\Program Files\Python*38*"
> -DPython3_FIND_REGISTRY=LAST
> -DLLDB_TEST_COMPILER=D:\src\llvm\build\ninja_dbg\bin\clang.exe
> ..\..\llvm-project\llvm -DLLVM_ENABLE_ZLIB=OFF
> -DLLVM_ENABLE_PROJECTS="clang;lld;lldb;clang-tools-extra;compiler-rt"
>
> My environment doesn't reference any other version of Python:
>
> D:\src\llvm\llvm-project>set | find /I "python"
> Path=C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Professional\VC\Tools\MSVC\14.24.28314\bin\HostX64\x64;C:\Program
> Files (x86)\Microsoft Visual
> Studio\2019\Professional\Common7\IDE\VC\VCPackages;C:\Program Files
> (x86)\Microsoft Visual
> Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program
> Files (x86)\Microsoft Visual
> Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team
> Explorer;C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Professional\MSBuild\Current\bin\Roslyn;C:\Program Files
> (x86)\Microsoft Visual Studio\2019\Professional\Team Tools\Performance
> Tools\x64;C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Professional\Team Tools\Performance Tools;C:\Program Files
> (x86)\Microsoft Visual
> Studio\Shared\Common\VSPerfCollectionTools\vs2019\\x64;C:\Program Files
> (x86)\Microsoft Visual
> Studio\Shared\Common\VSPerfCollectionTools\vs2019\;C:\Program Files
> (x86)\Windows Kits\10\bin\10.0.18362.0\x64;C:\Program Files (x86)\Windows
> Kits\10\bin\x64;C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Professional\\MSBuild\Current\Bin;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program
> Files (x86)\Microsoft Visual
> Studio\2019\Professional\Common7\IDE\;C:\Program Files (x86)\Microsoft
> Visual
> Studio\2019\Professional\Common7\Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\corpam;C:\Windows\ccmsetup;C:\Program
> Files\Git\cmd;C:\Program
> Files\Git\usr\bin;D:\src\util\GnuWin32\bin;C:\Program
> Files\doxygen\bin;C:\Program
> Files\Notepad++;D:\src\llvm\build\ninja_dbg\bin;D:\src\llvm\llvm-project\clang\tools\clang-format;C:\Program
> Files\Python38;D:\src\llvm\llvm-project\llvm\utils\git-svn\;D:\src\util;D:\src\util\swigwin-3.0.12;C:\Program
> Files (x86)\Microsoft Visual
> Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\Program
> Files (x86)\Microsoft Visual
> Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja
> __VSCMD_PREINIT_PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\corpam;C:\Windows

[lldb-dev] LLDB build searching for the wrong Python, again.

[Adrian McCarthy via lldb-dev]

After rebasing, my local LLDB builds have again broken because it goes
looking for the wrong Python DLL.  I'm searching through git logs, but I'm
not seeing a related change.

Does anyone know what causes CMake to get confused about which Python
versions are installed?

LINK : fatal error LNK1104: *cannot open file 'python37_d.lib'*

Why is it looking for 3.7?  My CMake command uses every hint I know about
to ensure that it finds Python 3.8:

cmake -GNinja -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
-DCMAKE_BUILD_TYPE=Debug -DLLDB_TEST_DEBUG_TEST_CRASHES=1
-DPYTHON_HOME="C:\Program Files\Python*38*" -DLLDB_PYTHON_HOME="C:\Program
Files\Python*38*" -DPython3_ROOT_DIR="C:\Program Files\Python*38*"
-DPython3_FIND_REGISTRY=LAST
-DLLDB_TEST_COMPILER=D:\src\llvm\build\ninja_dbg\bin\clang.exe
..\..\llvm-project\llvm -DLLVM_ENABLE_ZLIB=OFF
-DLLVM_ENABLE_PROJECTS="clang;lld;lldb;clang-tools-extra;compiler-rt"

My environment doesn't reference any other version of Python:

D:\src\llvm\llvm-project>set | find /I "python"
Path=C:\Program Files (x86)\Microsoft Visual
Studio\2019\Professional\VC\Tools\MSVC\14.24.28314\bin\HostX64\x64;C:\Program
Files (x86)\Microsoft Visual
Studio\2019\Professional\Common7\IDE\VC\VCPackages;C:\Program Files
(x86)\Microsoft Visual
Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program
Files (x86)\Microsoft Visual
Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team
Explorer;C:\Program Files (x86)\Microsoft Visual
Studio\2019\Professional\MSBuild\Current\bin\Roslyn;C:\Program Files
(x86)\Microsoft Visual Studio\2019\Professional\Team Tools\Performance
Tools\x64;C:\Program Files (x86)\Microsoft Visual
Studio\2019\Professional\Team Tools\Performance Tools;C:\Program Files
(x86)\Microsoft Visual
Studio\Shared\Common\VSPerfCollectionTools\vs2019\\x64;C:\Program Files
(x86)\Microsoft Visual
Studio\Shared\Common\VSPerfCollectionTools\vs2019\;C:\Program Files
(x86)\Windows Kits\10\bin\10.0.18362.0\x64;C:\Program Files (x86)\Windows
Kits\10\bin\x64;C:\Program Files (x86)\Microsoft Visual
Studio\2019\Professional\\MSBuild\Current\Bin;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program
Files (x86)\Microsoft Visual
Studio\2019\Professional\Common7\IDE\;C:\Program Files (x86)\Microsoft
Visual
Studio\2019\Professional\Common7\Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\corpam;C:\Windows\ccmsetup;C:\Program
Files\Git\cmd;C:\Program
Files\Git\usr\bin;D:\src\util\GnuWin32\bin;C:\Program
Files\doxygen\bin;C:\Program
Files\Notepad++;D:\src\llvm\build\ninja_dbg\bin;D:\src\llvm\llvm-project\clang\tools\clang-format;C:\Program
Files\Python38;D:\src\llvm\llvm-project\llvm\utils\git-svn\;D:\src\util;D:\src\util\swigwin-3.0.12;C:\Program
Files (x86)\Microsoft Visual
Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\Program
Files (x86)\Microsoft Visual
Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja
__VSCMD_PREINIT_PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\corpam;C:\Windows\ccmsetup;C:\Program
Files\Git\cmd;C:\Program
Files\Git\usr\bin;D:\src\util\GnuWin32\bin;C:\Program
Files\doxygen\bin;C:\Program
Files\Notepad++;D:\src\llvm\build\ninja_dbg\bin;D:\src\llvm\llvm-project\clang\tools\clang-format;*C:\Program
Files\Python38*
;D:\src\llvm\llvm-project\llvm\utils\git-svn\;D:\src\util;D:\src\util\swigwin-3.0.12

D:\src\llvm\llvm-project>where python
C:\Program Files\Python38\python.exe

D:\src\llvm\build\ninja_dbg>which python
/c/Program Files/Python38/python

I do not have 3.7 on my machine.  For a long while now, I've had to keep
exactly one version of Python on my machine specifically to prevent LLDB
builds from trying to mix versions.

But I'm stumped once again.

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

Re: [lldb-dev] [llvm-dev] buildbot slave able to run on python3

[Adrian McCarthy via lldb-dev]

Thanks, Galina, for working on the BuildBot update.  This update should
make it possible for us to stop referring to build machines as "slaves," a
terminology change that's overdue.

Let us know if there's anything I or others in the community can do to help
this along.

On Wed, Jun 17, 2020 at 12:55 PM Galina Kistanova via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Hello Jan,
>
> Yes. The buildbot migration to buildbot-2.x is a work in progress.
>
> Thanks
>
> Galina
>
> On Wed, Jun 17, 2020 at 12:51 AM Jan Kratochvil 
> wrote:
>
>> Hi Galina,
>>
>> there was:
>> [llvm-dev] Buildbot cleaning for zorg upgrade
>>
>> https://lists.llvm.org/pipermail/llvm-dev/2020-February/139503.html
>> "Zorg upgrade to a recent version of buildbot is coming."
>>
>> Do I understand it correctly there is a plan we could start using
>> buildbot-2.x
>> which is protocol-incompatible with the current buildbot-0.8.5 in use?
>>
>> buildbot-0.8.5 supports only python-2 (not python-3). Fedora 32 and
>> higher no
>> longer support python-2. I am stuck how to support recent Fedoras for
>> buildbot.
>>
>> buildbot-0.9.0 started to support python-3 but I guess buildbot-0.9.0 is
>> no
>> longer protocol-compatible with LLVM buildbot master. I have tried 0.9.0
>> but
>> it does not run on Fedora 32 (due to incompatible python-3 libraries) so
>> I would need to use some even newer buildbot version which I assume to be
>> definitely protocol-incompatible.
>>
>>
>> Jan
>>
>> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB_PYTHON_HOME

[Adrian McCarthy via lldb-dev]

:53 AM Adrian McCarthy 
>>>> wrote:
>>>>
>>>>> Thanks for the info.  Setting Python3_ROOT_DIR solves the problem.
>>>>>
>>>>> Looking at the cmake output from before setting Python3_ROOT_DIR,
>>>>> cmake looks for Python twice and finds it at the two different locations.
>>>>>
>>>>> Early on:
>>>>>
>>>>> -- Found PythonInterp: C:/Python36/python.exe (found version "3.6.8")
>>>>>
>>>>
>>> ^ This is using the "old" (CMake < 3.12) way of finding the Python
>>> interpreter.
>>>
>>>
>>>>
>>>>> Which looks good (modulo the incorrect slash direction).  But later:
>>>>>
>>>>> -- Found Python3: C:/Program Files (x86)/Microsoft Visual
>>>>> Studio/Shared/Python37_64/python.exe (found version "3.7.5") found
>>>>> components:  Interpreter Development
>>>>> -- Found PythonInterpAndLibs: C:/Program Files (x86)/Microsoft Visual
>>>>> Studio/Shared/Python37_64/libs/python37.lib
>>>>>
>>>>
>>> ^ This is using the "new" (CMake > 3.12) way of finding the Python
>>> interpreter and libraries.
>>>
>>>
>>>>
>>>>> Which is where the discrepancy comes in.  Note that only C:\Python36
>>>>> is in my PATH.
>>>>>
>>>>> It's frustrating that this keeps breaking.  Last time, I had to purge
>>>>> all but one Python installation from my machine to get it to make a
>>>>> consistent choice.  But I just upgraded to VS 2019, and it smuggled in its
>>>>> own version.
>>>>>
>>>>> So why are there two searches anyway?  And why do they have different
>>>>> algorithms that lead to different results?  (I'm not sure _how_ it ever
>>>>> found the Microsoft copy, since there's nothing in the process environment
>>>>> that points that way.)
>>>>>
>>>>
>>>> The reason there's two searches is because LLVM and LLDB have different
>>>> requirements. LLVM just needs a python interpreter to run some scripts.
>>>> LLDB on the other hand needs an interpreter and a matching Python library
>>>> to link against. Before CMake 3.12, finding the interpreter and the
>>>> libraries are two separate calls to find with no guarantees that they
>>>> match. This lead to all kinds of issues, where you're linking against one
>>>> version of Python and then trying to run the test suite with a totally
>>>> different interpreter. There were other problems on Windows, which meant
>>>> that we had our own hand-rolled implementation to find Python.
>>>>
>>>> This was all fixed in CMake 3.12. With FindPython{2,3} you know you'll
>>>> have a matching interpreter and library. It also fixed all the problems we
>>>> had to work around for Windows. Unfortunately, LLVM's minimum CMake version
>>>> is 3.4, so we can't use it yet. For LLDB on Windows we agreed that the
>>>> benefits of using FindPython3 are worth bumping the minimum required CMake
>>>> version (see lldb/CMakeLists.txt, line 2-4). Once LLVM moves to CMake 3.12
>>>> or later, all these problems should be fixed. We can then call FindPython3
>>>> once and rely on everything being consistent.
>>>>
>>>>
>>>>>
>>>>> On Thu, Feb 27, 2020 at 10:23 AM Jonas Devlieghere <
>>>>> jo...@devlieghere.com> wrote:
>>>>>
>>>>>> Hey Adrian,
>>>>>>
>>>>>> Config.h gets generated by expanding the corresponding CMake
>>>>>> variables. If you look at LLDBConfig.cmake, you can see that
>>>>>> LLDB_PYTHON_HOME is computed from PYTHON_EXECUTABLE. The problem appears
>>>>>> that somehow CMake ignored your specified PYTHON_HOME and decided to 
>>>>>> pick a
>>>>>> different Python. I'm not sure why though, because I use a similar CMake
>>>>>> invocation on Windows.
>>>>>>
>>>>>> > cmake ..\llvm-project\llvm -G Ninja
>>>>>> -DCMAKE_BUILD_TYPE=RelWithDebInfo
>>>>>> -DLLVM_ENABLE_PROJECTS="llvm;clang;lldb;lld" -DLLVM_ENABLE_ASSERTIONS=OFF
>>>>>> -DLLVM_ENABL

Re: [lldb-dev] LLDB_PYTHON_HOME

[Adrian McCarthy via lldb-dev]

python37.lib
>>>>
>>>
>> ^ This is using the "new" (CMake > 3.12) way of finding the Python
>> interpreter and libraries.
>>
>>
>>>
>>>> Which is where the discrepancy comes in.  Note that only C:\Python36 is
>>>> in my PATH.
>>>>
>>>> It's frustrating that this keeps breaking.  Last time, I had to purge
>>>> all but one Python installation from my machine to get it to make a
>>>> consistent choice.  But I just upgraded to VS 2019, and it smuggled in its
>>>> own version.
>>>>
>>>> So why are there two searches anyway?  And why do they have different
>>>> algorithms that lead to different results?  (I'm not sure _how_ it ever
>>>> found the Microsoft copy, since there's nothing in the process environment
>>>> that points that way.)
>>>>
>>>
>>> The reason there's two searches is because LLVM and LLDB have different
>>> requirements. LLVM just needs a python interpreter to run some scripts.
>>> LLDB on the other hand needs an interpreter and a matching Python library
>>> to link against. Before CMake 3.12, finding the interpreter and the
>>> libraries are two separate calls to find with no guarantees that they
>>> match. This lead to all kinds of issues, where you're linking against one
>>> version of Python and then trying to run the test suite with a totally
>>> different interpreter. There were other problems on Windows, which meant
>>> that we had our own hand-rolled implementation to find Python.
>>>
>>> This was all fixed in CMake 3.12. With FindPython{2,3} you know you'll
>>> have a matching interpreter and library. It also fixed all the problems we
>>> had to work around for Windows. Unfortunately, LLVM's minimum CMake version
>>> is 3.4, so we can't use it yet. For LLDB on Windows we agreed that the
>>> benefits of using FindPython3 are worth bumping the minimum required CMake
>>> version (see lldb/CMakeLists.txt, line 2-4). Once LLVM moves to CMake 3.12
>>> or later, all these problems should be fixed. We can then call FindPython3
>>> once and rely on everything being consistent.
>>>
>>>
>>>>
>>>> On Thu, Feb 27, 2020 at 10:23 AM Jonas Devlieghere <
>>>> jo...@devlieghere.com> wrote:
>>>>
>>>>> Hey Adrian,
>>>>>
>>>>> Config.h gets generated by expanding the corresponding CMake
>>>>> variables. If you look at LLDBConfig.cmake, you can see that
>>>>> LLDB_PYTHON_HOME is computed from PYTHON_EXECUTABLE. The problem appears
>>>>> that somehow CMake ignored your specified PYTHON_HOME and decided to pick 
>>>>> a
>>>>> different Python. I'm not sure why though, because I use a similar CMake
>>>>> invocation on Windows.
>>>>>
>>>>> > cmake ..\llvm-project\llvm -G Ninja
>>>>> -DCMAKE_BUILD_TYPE=RelWithDebInfo
>>>>> -DLLVM_ENABLE_PROJECTS="llvm;clang;lldb;lld" -DLLVM_ENABLE_ASSERTIONS=OFF
>>>>> -DLLVM_ENABLE_ZLIB=FALSE -DLLDB_ENABLE_PYTHON=TRUE
>>>>> -DPYTHON_HOME="C:/Program Files/Python36/"
>>>>>
>>>>> According to FindPython3 (
>>>>> https://cmake.org/cmake/help/v3.12/module/FindPython3.html), you can
>>>>> set Python3_ROOT_DIR as a hint. Can you give that a try? If that works we
>>>>> should populate that variable from PYTHON_HOME in
>>>>> FindPythonInterpAndLibs.cmake.
>>>>>
>>>>> Cheers,
>>>>> Jonas
>>>>>
>>>>> On Thu, Feb 27, 2020 at 10:10 AM Adrian McCarthy via lldb-dev <
>>>>> lldb-dev@lists.llvm.org> wrote:
>>>>>
>>>>>> Is there documentation on how lldb\include\lldb\host\config.h is
>>>>>> generated?  I'm again having the problem of the config trying to point to
>>>>>> the wrong Python installation.
>>>>>>
>>>>>> When I run cmake, I explicitly point PYTHON_HOME to C:\Python36 like
>>>>>> this:
>>>>>>
>>>>>> cmake -GNinja -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
>>>>>> -DCMAKE_BUILD_TYPE=Debug -DLLDB_TEST_DEBUG_TEST_CRASHES=1
>>>>>> -DPYTHON_HOME=C:\Python36
>>>>>> -DLLDB_TEST_COMPILER=D:\src\llvm\build\ninja\bin\clang.exe
>>>>>> ..\..\llvm-project\llvm -DLLVM_ENABLE_ZLIB=OFF
>>>>>> -DLLVM_ENABLE_PROJECTS="clang;lld;lldb"
>>>>>>
>>>>>> But the generated Config.h contains:
>>>>>>
>>>>>> #define LLDB_PYTHON_HOME "C:/Program Files (x86)/Microsoft Visual
>>>>>> Studio/Shared/Python37_64"
>>>>>>
>>>>>>
>>>>>> And the mismatch causes my build to fail because it goes looking for
>>>>>> python37_d.dll, which is apparently not part of the Microsoft 
>>>>>> distribution.
>>>>>> ___
>>>>>> lldb-dev mailing list
>>>>>> lldb-dev@lists.llvm.org
>>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>
>>>>>
>> I've put up a patch to use PYTHON_HOME as the hint:
>> https://reviews.llvm.org/D75275
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB_PYTHON_HOME

[Adrian McCarthy via lldb-dev]

 LLDB_PYTHON_HOME is
>>>> computed from PYTHON_EXECUTABLE. The problem appears that somehow CMake
>>>> ignored your specified PYTHON_HOME and decided to pick a different Python.
>>>> I'm not sure why though, because I use a similar CMake invocation on
>>>> Windows.
>>>>
>>>> > cmake ..\llvm-project\llvm -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo
>>>> -DLLVM_ENABLE_PROJECTS="llvm;clang;lldb;lld" -DLLVM_ENABLE_ASSERTIONS=OFF
>>>> -DLLVM_ENABLE_ZLIB=FALSE -DLLDB_ENABLE_PYTHON=TRUE
>>>> -DPYTHON_HOME="C:/Program Files/Python36/"
>>>>
>>>> According to FindPython3 (
>>>> https://cmake.org/cmake/help/v3.12/module/FindPython3.html), you can
>>>> set Python3_ROOT_DIR as a hint. Can you give that a try? If that works we
>>>> should populate that variable from PYTHON_HOME in
>>>> FindPythonInterpAndLibs.cmake.
>>>>
>>>> Cheers,
>>>> Jonas
>>>>
>>>> On Thu, Feb 27, 2020 at 10:10 AM Adrian McCarthy via lldb-dev <
>>>> lldb-dev@lists.llvm.org> wrote:
>>>>
>>>>> Is there documentation on how lldb\include\lldb\host\config.h is
>>>>> generated?  I'm again having the problem of the config trying to point to
>>>>> the wrong Python installation.
>>>>>
>>>>> When I run cmake, I explicitly point PYTHON_HOME to C:\Python36 like
>>>>> this:
>>>>>
>>>>> cmake -GNinja -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
>>>>> -DCMAKE_BUILD_TYPE=Debug -DLLDB_TEST_DEBUG_TEST_CRASHES=1
>>>>> -DPYTHON_HOME=C:\Python36
>>>>> -DLLDB_TEST_COMPILER=D:\src\llvm\build\ninja\bin\clang.exe
>>>>> ..\..\llvm-project\llvm -DLLVM_ENABLE_ZLIB=OFF
>>>>> -DLLVM_ENABLE_PROJECTS="clang;lld;lldb"
>>>>>
>>>>> But the generated Config.h contains:
>>>>>
>>>>> #define LLDB_PYTHON_HOME "C:/Program Files (x86)/Microsoft Visual
>>>>> Studio/Shared/Python37_64"
>>>>>
>>>>>
>>>>> And the mismatch causes my build to fail because it goes looking for
>>>>> python37_d.dll, which is apparently not part of the Microsoft 
>>>>> distribution.
>>>>> ___
>>>>> lldb-dev mailing list
>>>>> lldb-dev@lists.llvm.org
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>
>>>>
> I've put up a patch to use PYTHON_HOME as the hint:
> https://reviews.llvm.org/D75275
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB_PYTHON_HOME

[Adrian McCarthy via lldb-dev]

Thanks for the info.  Setting Python3_ROOT_DIR solves the problem.

Looking at the cmake output from before setting Python3_ROOT_DIR, cmake
looks for Python twice and finds it at the two different locations.

Early on:

-- Found PythonInterp: C:/Python36/python.exe (found version "3.6.8")

Which looks good (modulo the incorrect slash direction).  But later:

-- Found Python3: C:/Program Files (x86)/Microsoft Visual
Studio/Shared/Python37_64/python.exe (found version "3.7.5") found
components:  Interpreter Development
-- Found PythonInterpAndLibs: C:/Program Files (x86)/Microsoft Visual
Studio/Shared/Python37_64/libs/python37.lib

Which is where the discrepancy comes in.  Note that only C:\Python36 is in
my PATH.

It's frustrating that this keeps breaking.  Last time, I had to purge all
but one Python installation from my machine to get it to make a consistent
choice.  But I just upgraded to VS 2019, and it smuggled in its own version.

So why are there two searches anyway?  And why do they have different
algorithms that lead to different results?  (I'm not sure _how_ it ever
found the Microsoft copy, since there's nothing in the process environment
that points that way.)

On Thu, Feb 27, 2020 at 10:23 AM Jonas Devlieghere 
wrote:

> Hey Adrian,
>
> Config.h gets generated by expanding the corresponding CMake variables. If
> you look at LLDBConfig.cmake, you can see that LLDB_PYTHON_HOME is computed
> from PYTHON_EXECUTABLE. The problem appears that somehow CMake ignored your
> specified PYTHON_HOME and decided to pick a different Python. I'm not sure
> why though, because I use a similar CMake invocation on Windows.
>
> > cmake ..\llvm-project\llvm -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DLLVM_ENABLE_PROJECTS="llvm;clang;lldb;lld" -DLLVM_ENABLE_ASSERTIONS=OFF
> -DLLVM_ENABLE_ZLIB=FALSE -DLLDB_ENABLE_PYTHON=TRUE
> -DPYTHON_HOME="C:/Program Files/Python36/"
>
> According to FindPython3 (
> https://cmake.org/cmake/help/v3.12/module/FindPython3.html), you can set
> Python3_ROOT_DIR as a hint. Can you give that a try? If that works we
> should populate that variable from PYTHON_HOME in
> FindPythonInterpAndLibs.cmake.
>
> Cheers,
> Jonas
>
> On Thu, Feb 27, 2020 at 10:10 AM Adrian McCarthy via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Is there documentation on how lldb\include\lldb\host\config.h is
>> generated?  I'm again having the problem of the config trying to point to
>> the wrong Python installation.
>>
>> When I run cmake, I explicitly point PYTHON_HOME to C:\Python36 like this:
>>
>> cmake -GNinja -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
>> -DCMAKE_BUILD_TYPE=Debug -DLLDB_TEST_DEBUG_TEST_CRASHES=1
>> -DPYTHON_HOME=C:\Python36
>> -DLLDB_TEST_COMPILER=D:\src\llvm\build\ninja\bin\clang.exe
>> ..\..\llvm-project\llvm -DLLVM_ENABLE_ZLIB=OFF
>> -DLLVM_ENABLE_PROJECTS="clang;lld;lldb"
>>
>> But the generated Config.h contains:
>>
>> #define LLDB_PYTHON_HOME "C:/Program Files (x86)/Microsoft Visual
>> Studio/Shared/Python37_64"
>>
>>
>> And the mismatch causes my build to fail because it goes looking for
>> python37_d.dll, which is apparently not part of the Microsoft distribution.
>> ___
>> 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] LLDB_PYTHON_HOME

[Adrian McCarthy via lldb-dev]

Is there documentation on how lldb\include\lldb\host\config.h is
generated?  I'm again having the problem of the config trying to point to
the wrong Python installation.

When I run cmake, I explicitly point PYTHON_HOME to C:\Python36 like this:

cmake -GNinja -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
-DCMAKE_BUILD_TYPE=Debug -DLLDB_TEST_DEBUG_TEST_CRASHES=1
-DPYTHON_HOME=C:\Python36
-DLLDB_TEST_COMPILER=D:\src\llvm\build\ninja\bin\clang.exe
..\..\llvm-project\llvm -DLLVM_ENABLE_ZLIB=OFF
-DLLVM_ENABLE_PROJECTS="clang;lld;lldb"

But the generated Config.h contains:

#define LLDB_PYTHON_HOME "C:/Program Files (x86)/Microsoft Visual
Studio/Shared/Python37_64"


And the mismatch causes my build to fail because it goes looking for
python37_d.dll, which is apparently not part of the Microsoft distribution.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Odd behavior with Python on Windows (loading 2 copies of liblldb.dll/_lldb.pyd)

[Adrian McCarthy via lldb-dev]

Just guessing:  Does either machine have more than one Python installation?

Windows Server is, by default, more locked down than the standard editions,
which can affect the search path.  Perhaps you're not getting the Python
you think you're getting on one of the machines.

Are both machines 64-bit?  Are you launching Python from a 32- or 64-bit
process?  Is it the same on both machines?



On Fri, Feb 21, 2020 at 1:02 PM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I first noticed this issue when running
> print(lldb.SBHostOS.GetLLDBPythonPath()) in the script interpreter. It
> worked as expected on Linux and with an LLDB that I built on my machine,
> but when I ran it in an LLDB that our buildbots built, I got the wrong
> value – /lib/site-packages/lib/site-packages.
>
>
>
> I checked both versions using Process Explorer to see loaded dlls. The
> version I built on my Windows machine (Win 10, VS 2017, Python 3.5.1,
> works) shows liblldb.dll. The version built on the bot (Windows Server
> 2016, VS 2017, Python 3.5.1, but doesn’t work) shows _lldb.pyd and
> liblldb.dll.
>
>
>
> In both cases we use cmake to build a VS solution. On my machine I built
> lldb in Visual Studio. On the bot we call msbuild to build the RELEASE
> configuration. The bot then does an install. I also did an install, and my
> installed version works correctly.
>
>
>
> Does anybody have any idea why lldb built on the bot would load the dll
> twice, but lldb built on my machine would load it once?
>
>
>
> Ted
> ___
> 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] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

[Adrian McCarthy via lldb-dev]

Yes, I think it's pretty reasonable to expect a specific version of Python,
especially if the pre-built Python DLLs for Windows are still built with
versions as old as VS 2013.  Once you get to VS 2015 or 2017, I think the
compatibility improves.

Perhaps the best thing for the pre-built LLDB is to include the right
Python DLL in the distro, assuming the licensing allows that.

The more sophisticated solutions are probably more work than is justified
by the value.

On Fri, Nov 22, 2019 at 8:29 AM Ted Woodward  wrote:

>
>
> > > * Dynamically load any supported Python DLL if/when needed
> > That might be tricky since the different versions are not binary
> compatible in
> > general. But it is possible, as Apple folks have shown, though it
> amounts to
> > building multiple copies of ScriptInterpreterPython and then choosing the
> > right one at runtime.
>
> It's not just the python dll; it's the modules directory as well. My
> experiments with different versions of Python on Linux led me to just ship
> the right python with our distribution.
>
> I saw things like building with 2.7.6 but using the 2.7.3 library/modules
> (and vice versa) would crash, and building with 2.7.6 but running with
> 2.6.x seemed to be OK, mostly. On Windows, I had crashes when loading
> Python 2.7.8 from python.org (built with VS 2008) in lldb built with VS
> 2013, so you have to think about other library dependencies too.
>
> My conclusion - you MUST use the same python that lldb was built with.
> Period.
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

[Adrian McCarthy via lldb-dev]

Yes, that sounds plausible, but I don't recall for sure.  I think there's a
build-time option to say you don't want Python at all, but I can't remember
if there was a load-as-needed option.

In any event, the current situation is what it is.  What's feasible and
worth doing for the future?

* Hard dependency (as we have right now)
* Dynamically load Python DLL on startup if it exists, or provide a better
error message with instructions
* Dynamically load Python DLL on startup if it exists, otherwise disable
Python-dependent features
* Dynamically load a specific version of the Python DLL if/when needed
* Dynamically load any supported Python DLL if/when needed





On Thu, Nov 21, 2019 at 1:57 PM Leonard Mosescu  wrote:

> What kind of behavior did you expect?
>
> I could be wrong, but I thought that previous versions of LLDB would use
> LoadLibrary() instead of linking to the import library?
>
> --
> *From:* Pavel Labath 
> *Sent:* Wednesday, November 20, 2019 11:32 PM
> *To:* Adrian McCarthy ; Leonard Mosescu <
> lmose...@nvidia.com>
> *Cc:* lldb-dev@lists.llvm.org 
> *Subject:* Re: [lldb-dev] The pre-built Windows LLDB binary has a
> dependency on an external python36.dll?
>
> On 20/11/2019 23:53, Adrian McCarthy via lldb-dev wrote:
> > That said, I didn't expect an explicit dependency on python36.dll.
>
> What kind of behavior did you expect?
>
> pl
> --
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
> --
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

[Adrian McCarthy via lldb-dev]

Here are some possibly related reviews.  Note that some of these were
abandoned, but I'm including them because the comments might give some
context.

https://reviews.llvm.org/D69684 
https://reviews.llvm.org/D69931
https://reviews.llvm.org/D67942
https://reviews.llvm.org/D69535
https://reviews.llvm.org/D68613
https://reviews.llvm.org/D68442


https://reviews.llvm.org/D68613

On Wed, Nov 20, 2019 at 2:53 PM Adrian McCarthy  wrote:

> There has been a lot of churn in the build process for Python on Windows
> over the past couple months.
>
> Older versions included a pre-built Python DLL on Windows because of ABI
> compatibility.  That issue is resolved, though, and I thought that was
> already over by version 7 or earlier.
>
> Because other compatibility issues, it was decided that the Windows
> version could depend on 3.6+ while non-Windows versions might still rely on
> slightly older versions of Python.
>
> That said, I didn't expect an explicit dependency on python36.dll.  Please
> file a bug.  I'll look through the revision history and see if I can loop
> in the folks who've been making changes in this area.  I suspect it was an
> unintended side effect.
>
> On Wed, Nov 20, 2019 at 1:59 PM Leonard Mosescu via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I just installed the pre-built LLVM9 binaries on a Windows machine and I
>> noticed that LLDB.exe imports from python36.dll. Was this an intentional
>> change from LLVM8? (which doesn't depend on external python DLLs)
>>
>> Trying to use the LLDB that comes with LLVM9, you'd get a pop-up
>> complaining that python36.dll was not found (unless you happen to have on
>> in your PATH) and LLDB fails to start.
>>
>> Thanks,
>> Leonard.
>>
>> --
>> This email message is for the sole use of the intended recipient(s) and
>> may contain confidential information.  Any unauthorized review, use,
>> disclosure or distribution is prohibited.  If you are not the intended
>> recipient, please contact the sender by reply email and destroy all copies
>> of the original message.
>> --
>> ___
>> 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] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

[Adrian McCarthy via lldb-dev]

There has been a lot of churn in the build process for Python on Windows
over the past couple months.

Older versions included a pre-built Python DLL on Windows because of ABI
compatibility.  That issue is resolved, though, and I thought that was
already over by version 7 or earlier.

Because other compatibility issues, it was decided that the Windows version
could depend on 3.6+ while non-Windows versions might still rely on
slightly older versions of Python.

That said, I didn't expect an explicit dependency on python36.dll.  Please
file a bug.  I'll look through the revision history and see if I can loop
in the folks who've been making changes in this area.  I suspect it was an
unintended side effect.

On Wed, Nov 20, 2019 at 1:59 PM Leonard Mosescu via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I just installed the pre-built LLVM9 binaries on a Windows machine and I
> noticed that LLDB.exe imports from python36.dll. Was this an intentional
> change from LLVM8? (which doesn't depend on external python DLLs)
>
> Trying to use the LLDB that comes with LLVM9, you'd get a pop-up
> complaining that python36.dll was not found (unless you happen to have on
> in your PATH) and LLDB fails to start.
>
> Thanks,
> Leonard.
>
> --
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
> --
> ___
> 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] issue with lldb9 and python3.5

[Adrian McCarthy via lldb-dev]

+1 Yes, for Windows, I'd be happy if we said Python 3.6+.

On Mon, Oct 28, 2019 at 10:07 AM Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> On Mon, Oct 28, 2019 at 10:04 AM Jonas Devlieghere
>  wrote:
> >
> > On Mon, Oct 28, 2019 at 9:32 AM Tom Stellard 
> wrote:
> > >
> > > On 10/28/2019 09:29 AM, Jonas Devlieghere wrote:
> > > > Yes, Python 3.5 is not supported. We "officially" support Python 2.7
> > > > and Python 3.7. I'm sorry if we forgot that in the release notes.
> > > >
> > >
> > > Is there a specific reason why 3.5 is not supported?  Is it
> > > because of this issue?
> >
> > Not really other than the lack of testing/CI.
> >
> > - The Linux bots are all running with Python 2.7.
> > - I know that on macOS we ran into issues with some older versions. I
> > don't remember if it was this particular issue and I'm not even sure
> > if that was using Python 3.5 or Python 3.6. Our bots on GreenDragon
> > all run with Python 3.7.
> > - Stella's Windows bot is running Python 3.6 so we should consider
> > that supported as well.
>
> For completeness, Python 2.7 is not supported on Windows at all. The
> docs specify Python 3.5 or later. Maybe we should bump that to 3.6
> too?
>
> >
> > >
> > > -Tom
> > >
> > > > On Mon, Oct 28, 2019 at 7:06 AM Tom Stellard via lldb-dev
> > > >  wrote:
> > > >>
> > > >> + lldb-dev
> > > >>
> > > >> On 10/28/2019 07:06 AM, Tom Stellard wrote:
> > > >>> On 10/28/2019 03:50 AM, Romaric Jodin via lldb-dev wrote:
> > >  Hi everyone,
> > > 
> > >  I have lldb crashing since I've updated to lldb9. Seems like
> there is a issue with python3.5. Everything seems to work fine with
> python3.7.
> > >  Am I missing something? Or is it a known issue?
> > > 
> > > >>>
> > > >>> We have seen this too with python 3.6, but we haven't found the
> root cause yet.
> > > >>> For now, we've worked around this by disabling the readline module
> with the
> > > >>> attached patch.
> > > >>>
> > > >>> -Tom
> > > >>>
> > >  $ lldb
> > >  (lldb) script
> > >   #0 0x7f3d324c9c2a
> llvm::sys::PrintStackTrace(llvm::raw_ostream&)
> (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bfc2a)
> > >   #1 0x7f3d324c7af5 llvm::sys::RunSignalHandlers()
> (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bdaf5)
> > >   #2 0x7f3d324c7c0c SignalHandler(int)
> (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bdc0c)
> > >   #3 0x7f3d31bfe0e0 __restore_rt
> (/lib/x86_64-linux-gnu/libpthread.so.0+0x110e0)
> > >   #4 0x7f3d2d18f81b PyModule_GetState
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x6881b)
> > >   #5 0x7f3d230e1621 _init (/usr/lib/python3.5/lib-dynload/
> readline.cpython-35m-x86_64-linux-gnu.so <
> http://readline.cpython-35m-x86_64-linux-gnu.so>+0x3621)
> > >   #6 0x7f3d2e3dece1 rl_initialize
> (/usr/lib/x86_64-linux-gnu/libedit.so.2+0x1dce1)
> > >   #7 0x7f3d230e1f3e _init (/usr/lib/python3.5/lib-dynload/
> readline.cpython-35m-x86_64-linux-gnu.so <
> http://readline.cpython-35m-x86_64-linux-gnu.so>+0x3f3e)
> > >   #8 0x7f3d2d32d710 _PyImport_LoadDynamicModuleWithSpec
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x206710)
> > >   #9 0x7f3d2d330fe7
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x209fe7)
> > >  #10 0x7f3d2d198259 PyCFunction_Call
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x71259)
> > >  #11 0x7f3d2d2c8ff2 PyEval_EvalFrameEx
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a1ff2)
> > >  #12 0x7f3d2d38b074
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074)
> > >  #13 0x7f3d2d2c7adf PyEval_EvalFrameEx
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a0adf)
> > >  #14 0x7f3d2d2c96ad PyEval_EvalFrameEx
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
> > >  #15 0x7f3d2d2c96ad PyEval_EvalFrameEx
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
> > >  #16 0x7f3d2d2c96ad PyEval_EvalFrameEx
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
> > >  #17 0x7f3d2d2c96ad PyEval_EvalFrameEx
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
> > >  #18 0x7f3d2d38b074
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074)
> > >  #19 0x7f3d2d38b153 PyEval_EvalCodeEx
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264153)
> > >  #20 0x7f3d2d21e558
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0xf7558)
> > >  #21 0x7f3d2d2faa37 PyObject_Call
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1d3a37)
> > >  #22 0x7f3d2d2fce1b _PyObject_CallMethodIdObjArgs
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1d5e1b)
> > >  #23 0x7f3d2d32effa PyImport_ImportModuleLevelObject
> (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x207ffa)
> > >  #24 0x7f3d2d2cd248

Re: [lldb-dev] test setup for windows -- makefiles

[Adrian McCarthy via lldb-dev]

I'm not sure this is entirely up to date, but I'd start here, especially
the Software section:

https://llvm.org/docs/GettingStartedVS.html

We get most of those unix-y tools on Windows via GnuWin32.  For LLDB
development, you almost certainly want a Python 3 rather than the
recommended 2.7.

There's also some LLDB-specific advice for setting up on Windows:

https://lldb.llvm.org/resources/build.html#windows

Feel free to ask more questions if those links are
confusing/wrong/out-of-date/incomplete/etc.



On Wed, Oct 9, 2019 at 5:12 PM Larry D'Anna via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi lldb-dev.
>
> Most of the tests build binaries to test with using Makefiles, and these
> Makefiles use all sorts of unix commands
> like sed and uname.And yet I see the build-bot is running `ninja-check
> lldb` on windows.
>
>
> I thought maybe if I installed MinGW that would have enough stuff in it to
> run the tests, but that doesn’t seem to be
> true.
>
> Does anyone have instructions for how to set up a windows test host for
> LLDB?   Or  a list of dependencies that
> should be installed?
>
> Thanks.
> ___
> 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] Who sets the 10-minute timeouts?

[Adrian McCarthy via lldb-dev]

On Wed, Aug 14, 2019 at 2:47 PM Jim Ingham  wrote:

>
>
> > On Aug 14, 2019, at 1:41 PM, Adrian Prantl via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> >
> >
> >> On Aug 14, 2019, at 11:26 AM, Adrian McCarthy via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> A recent change is causing several LLDB tests on Windows to fail and
> several more to time out, which I intend to look into.
> >>
> >> It appears the timeout period is set to 600 seconds (10 minutes), which
> seems excessive and causes the Windows build bot to spend lots of time
> waiting.  (e.g.,
> http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/7819/steps/test/logs/stdio
> )
> >>
> >> Is there a reason why the timeouts are set that long?  What would be a
> reasonable value?
> >
> > I recently increased/unified several internal timeouts throughout LLDB (
> https://reviews.llvm.org/D60340) in reaction to bots failing randomly on
> heavily used machines, particularly when ASAN is enabled, which can cause
> surprisingly long delays.
> >
> > Since the normal operation should be that no tests fail, waiting an
> extra 10 minutes in the exceptional case that a test does fail seems more
> desirable than the chance of a working test failing because of too-small
> timeout. Therefore, I'd rather pick an excessively large per-test timeout
> to be safe.
>
> This is a little pedantic, but tests that fail some assert also won't
> trigger the timeout.  It should only be tests that fail by stalling


FYI:  There are six tests stalling on Windows.  They've been doing it long
enough that the bot history no longer shows the last good build and the
grid view never shows anything other than "building" because it can no
longer keep up with the rate of submissions.

There are also many tests actually failing on Windows.  It's time consuming
to bisect when the timeouts add 10 minutes to every step.


> - for instance you expected to hit a breakpoint but never did - that
> trigger the timeout.  That should be even less frequent that just test
> failures.
>
> Jim
>
> >
> > -- adrian
> > ___
> > 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] Who sets the 10-minute timeouts?

[Adrian McCarthy via lldb-dev]

A recent change is causing several LLDB tests on Windows to fail and
several more to time out, which I intend to look into.

It appears the timeout period is set to 600 seconds (10 minutes), which
seems excessive and causes the Windows build bot to spend lots of time
waiting.  (e.g.,
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/7819/steps/test/logs/stdio
)

Is there a reason why the timeouts are set that long?  What would be a
reasonable value?

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

[lldb-dev] How to debug "Python memory allocator called without holding the GIL" during LLDB tests?

[Adrian McCarthy via lldb-dev]

Several LLDB tests on Windows are now failing for me like this:

Fatal Python error: Python memory allocator called without holding the GIL

Current thread 0x081c (most recent call first):
  File "D:\src\llvm\build\mono\lib\site-packages\lldb\__init__.py", line
14461 in GetNumChildren
  File
"D:\src\llvm\mono\llvm-project\lldb\packages\Python\lldbsuite\test\python_api\formatters\TestFormattersSBAPI.py",
line 478 in test_force_synth_off
  File
"D:\src\llvm\mono\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py",
line 1738 in test_method
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\case.py",
line 413 in runMethod
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\case.py",
line 383 in run
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\case.py",
line 458 in __call__
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\suite.py",
line 117 in _wrapped_run
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\suite.py",
line 115 in _wrapped_run
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\suite.py",
line 85 in run
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\suite.py",
line 66 in __call__
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\runner.py",
line 165 in run
  File
"D:\src\llvm\mono\llvm-project\lldb\packages\Python\lldbsuite\test\dotest.py",
line 1443 in run_suite
  File "D:/src/llvm/mono/llvm-project/lldb/test/dotest.py", line 7 in


I'm not sure how to go about debugging the problem.  Note that the crash is
in SWIG-generated code called by standard SBAPI tests that used to work
just fine.  (There are actually a few different tests that trigger the
problem, but TestFormattersSBAPI.py is typically the first and sometimes
only one on any given run.)

I tried bisecting, but it turns out the problem coincided with an
environmental change rather than a patch.

My environment changed to accommodate rL366243, which tries to ensure that
the version of the Python interpreter detected by CMake matches the version
of the Python libraries found by LLDBConfig, which has special logic on
Windows so that the user can override the version of Python that LLDB uses.

That version check failed because CMake detected Python 2.7 rather than
Python 3.6, which I had specified with PYTHON_HOME.  This apparently has
happened for a very long time, but it had never caused a problem until the
version check was added.  As far as I can tell, on Windows, LLDB uses the
Python from PYTHON_HOME and/or the PATH and completely ignores the one
CMake finds.

The only way I could satisfy the version check was to eliminate Python 2.7
from my machine so that CMake had no choice but to detect 3.6.

There was additional confusion, as the Python 2.7 uninstaller also removed
make from my machine!  (Weird, right?)

Ever since I restored make, running LLDB tests results in the error and
stack reported at the top of this message.  (Annoyingly, this sometimes
causes a popup dialog that must be manually dismissed.  Once you've
dismissed it, the tests are usually hung.  Canceling out of the tests
leaves zombie Python processes that hold locks on various files, so there
are additional manual steps to clean up.)

To summarize, the environmental changes are:

1.  Only one version of Python remains on the machine:

Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 24 2018, 00:16:47) [MSC v.1916 64
bit (AMD64)] on win32

2.  Whatever version of make I was using vanished and was replaced by the
one that comes with GnuWin32:

GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-pc-mingw32

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

Re: [lldb-dev] Symbol Server for LLDB

[Adrian McCarthy via lldb-dev]

I know several people here have been looking for a generic, cross-platform
way to locate symbols.  One idea here was to make the symbol fetcher a
Python script that could use the SBAPI to interrogate the debugger to
determine what's needed.  This isn't that different than a separate binary,
but it might make it easier for users to customize it for their environment.

Anyway, I like the idea of a query out to possibly user-provided symbol
fetcher, regardless of the details.

On Fri, Jul 12, 2019 at 3:29 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> This is currently handled in each Platform subclass. The only platform
> that has the ability to locate symbol automatically are the Darwin
> platforms and those use DebugSymbols.framework to locate the symbols.
>
> That being said, I have been thinking about doing this in a generic way
> that would work for all platforms. My idea is to allow a setting that would
> be set that could specify a executable that would get run with arguments
> that specify the data to be looked up. My first inclination was we would
> pass down a JSON request, and the executable would try to fetch the binary
> requested the JSON, and responsd with a JSON reply specifying where the
> symbols were fetched locally (or made available on a network mount). So we
> might send JSON request that looks something like:
>
> { "type": "symbol-fetch", "basename": "libfoo.so", "uuid":
> "307E4F5E-EB63-3CC8-B940-9F89BB46098D", "arch": "armv7-apple-ios" }
>
> and it could respond with success:
> { "status": "success", "path": "/path/to/cache/.../debug/info/libfoo.so" }
>
> We can include more details in here, like the source path remapping that
> might need to happen so paths can be remapped and used in LLDB to display
> the sources correctly. For info on how we did this for
> DebugSymbols.framework on Darwin see:
>
> http://lldb.llvm.org/use/symbols.html
>
> We specified the "arch" in the original packet so we can have one or more
> symbol servers registered with the LLDB settings:
>
> (lldb) setting append target.symbol-servers /path/to/ios-symbol-server
> (lldb) setting append target.symbol-servers /path/to/linux-symbol-server
>
> and each binary could respond with an status stating that the binary isn't
> support by a plugin:
>
> { "status": "unsupported" }
>
> or return an error if we found the right plug-in but the file wasn't
> available for some reason:
>
> { "status": "failed", "error": "file not available in ..." }
>
> The idea is the Platform.cpp would be the one that would run these scripts
> if the settings were set.
>
> If we want to get really fancy the symbol-server binaries could also be
> asked to return a list of supported target triples so we could avoid call
> all of the symbol servers in the "target.symbol-servers" list. So we would
> ask each symbol server to register itself:
>
> { "type": "register" }
>
> And they could respond with a list of supported triples or other data:
>
> { "supported-arch": [ "*-apple-macos", "*-apple-ios", "*-tvos-ios" ] }
>
> Comments?
>
> On Mar 24, 2019, at 11:11 PM, Murali Venu Thyagarajan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hello,
>
> Is there a way to setup a symbol server for lldb just like how I could
> setup a centralized and indexed symbol server for Windbg. Please let me
> know.
>
> Thanks,
> Murali
> ___
> 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] Trouble running Python tests on Windows

[Adrian McCarthy via lldb-dev]

I can confirm that there are problems building with Swig 4.

I've also just found that there's a bug in versions of Swig before 4 that
makes the code it generates incompatible with Python 3.7.  (See lldb-dev@
for a message I just sent out about this.)

Python 3.6 with Swig 3.0.12 is working well for me on Windows.

On Fri, May 31, 2019 at 9:15 AM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Run the cmake gui, and point it to the correct source and build
> directories. Look for key “SWIG_EXECUTABLE”. If it doesn’t exist, set it to
> your swig exe. Mine is C:/swigwin-3.0.12/swig.exe , for example. If you
> change it, hit the configure and then generate buttons, then rebuild and
> rerun the tests.
>
>
>
> I haven’t built with swig 4, just swig 3. I’ll let someone else answer if
> swig 4 works!
>
>
>
> *From:* lldb-dev  *On Behalf Of *Alexandre
> Ganea via lldb-dev
> *Sent:* Friday, May 31, 2019 10:42 AM
> *To:* lldb-dev@lists.llvm.org
> *Subject:* [EXT] [lldb-dev] Trouble running Python tests on Windows
>
>
>
> Hi,
>
>
>
> I can’t seem to run the lldb python tests on my Windows 10 setup. I use
> the following cmd-line to generate:
>
>
>
> cmake -G Ninja f:/svn/llvm -DCMAKE_BUILD_TYPE=Release
> -DLLVM_OPTIMIZED_TABLEGEN=true -DLLVM_EXTERNAL_LLD_SOURCE_DIR=f:/svn/lld
> -DLLVM_EXTERNAL_CLANG_SOURCE_DIR=f:/svn/clang -DLLVM_TOOL_LLD_BUILD=true
> -DLLVM_TOOL_CLANG_BUILD=true -DLLVM_ENABLE_PDB=true
> -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_EXTERNAL_LLDB_SOURCE_DIR=f:/svn/lldb
> -DLLVM_TOOL_LLDB_BUILD=true
> -DPYTHON_HOME="C:\Users\aganea\AppData\Local\Programs\Python\Python37"
>
>
>
> Followed by: ninja check-all, which ends up in a bunch of:
>
>
>
>  TEST 'lldb-Suite ::
> tools/lldb-server/TestAppleSimulatorOSType.py' FAILED 
>
> Unable to find 'RESULT: PASSED' in dotest output:
>
>
>
> lldb version 9.0.0 (https://aga...@llvm.org/svn/llvm-project/lldb/trunk
> revision 361826)
>
>   clang revision 361826
>
>   llvm revision 361826
>
> LLDB library dir: F:\svn\buildninja\bin
>
> LLDB import library dir: F:\svn\buildninja\bin\..\lib
>
> Traceback (most recent call last):
>
>   File "F:/svn/lldb/test/dotest.py", line 7, in 
>
> lldbsuite.test.run_suite()
>
>   File "F:\svn\lldb\packages\Python\lldbsuite\test\dotest.py", line 1243,
> in run_suite
>
> import lldb
>
>   File "F:\svn\buildninja\lib\site-packages\lldb\__init__.py", line 1500,
> in 
>
> class SBAddress(object):
>
>   File "F:\svn\buildninja\lib\site-packages\lldb\__init__.py", line 1675,
> in SBAddress
>
> __swig_getmethods__["module"] = GetModule
>
> NameError: name '__swig_getmethods__' is not defined
>
>
>
> Swig 4.0.0 is there in %PATH%. I’m using MSVC 19.16.27031.1 for compiling.
> I’ve tried with Clang 8.0, same issues.
>
> Any idea on what could be missing?
>
>
>
> Thanks in advance!
>
> Alex.
> ___
> 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] Swig/Python version incompatibility

[Adrian McCarthy via lldb-dev]

tl;dr:  To avoid a compatibility problem with Swig, don't upgrade to Python
3.7.

While chasing down the cause of lots of lldb test failures on Windows, I
discovered that there's a compatibility bug with Python 3.7 and Swig 3.0.12.

Python 3.7 tighted up the tp_new API, which SWIG generates calls to.
Specifically, you can see assertion failures for "PyTuple_Check(args)" for
pretty much any invocation of the SBAPI.  (This appears only if you're
using a debug version of Python, because the assertion is in the Python
implementation.)

Swig 4.0 has a fix to satisfy Python's tighter expectation, so I upgraded
to Swig 4.0, but then other problems surfaced (like undefined references to
__swig_getmethods__).

Some context:  https://github.com/swig/swig/issues/1321

So, for now, it looks like we have to stick with Python 3.6/Swig 3.0.12.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

[Adrian McCarthy via lldb-dev]

I'd have no objection to individual .cpp files having a few using
declarations for the specific types that file cares about:

...
#include "llvm/ADT/ArrayRef.h"
#include "llvm/ADT/Optional.h"
...

using llvm::ArrayRef;
using llvm::Optional;

And then the rest of the file uses the unqualified `ArrayRef` and
`Optional`.  If it's just a few commonly used types, this get the
improvements in typability and readability that you're looking for.

But keeps the aliasing local to the implementation file, which reduces the
risks of conflicts and helps newbies understand where these types come from.

It also avoids the headaches of forward declarations.

LLDB has only a couple using declarations like this right now, but other
parts of LLVM seem to do this more liberally.


On Thu, Apr 18, 2019 at 7:31 AM Pavel Labath  wrote:

> Thanks for the replies. I was hoping to get more positive feedback for
> this, so given the current mixed-feelings replies, I think I'll just
> give up on this idea, unless a more vocal supporter appears (probably
> not the best idea to send this out just before the easter holidays).
>
> In the mean time, here are my thoughts on what was said.
>
>
> On 18/04/2019 01:54, Adrian McCarthy wrote:
> > I don't have a strong opinion, but I lean against the idea for two
> reasons:
> >
> > 1.  The `llvm::` prefixes don't really hinder readability for me.
> > They're like `std::` prefixes on all the C++ standard library types,
> > which I'm perfectly happy to type and read--moreso than using
> > declarations.  Sure, anybody who's been here a while knows which classes
> > come from LLVM, but new folks might build that knowledge by seeing the
> > prefixes.
>
> Yeah, I was wondering why I'm bothered by typing "llvm::" and not by
> "std::". I concluded that this is down to two things:
> 1. we don't use that many things from the std:: namespace actually.
> Pretty much everything except std::string and std::vector is discouraged
> because llvm has better alternatives
>
> 2. llvm names are longer. This is not just due to to "llvm" prefix,
> which is just one char, but also the class names themselves tend to be
> longer. std::vector vs llvm::SmallVector, std::map vs. llvm::DenseMap,
> std::string vs. llvm::StringRef, etc.
>
> This effect gets multiplied once you start to combine things. For
> instance if you have a function returning Expected> (which
> is not an unreasonable thing to do), then by the time you spell out the
> full type, more than half of your usable horizontal space is gone.
> Because of this, I've found myself using "auto" or relying on ADL more
> and more often, which I don't consider very ideal either.
>
> I don't think using "auto" is always a good choice because it hides
> interesting details. E.g. an Optional can look a lot like
> Expected, but there are differences in how they are supposed used
> which should not be overlooked (I wish I was able to type
> "Expected" :P). And ADL is sometimes just too magical...
>
>
> >
> > 2.  I'm not a fan of forward declaring types provided by other parts of
> > the code, as it requires intimate knowledge of implementation details.
> > In practice this may not matter much for the types we're considering.
> > If it grew more widespread, however, I'd be more concerned.  (Somewhere
> > I've written a long explanation of this opinion.  I'll go search for it
> > if anyone cares.  The Google style guide discourages forward
> > declarations, but the rationale given there isn't as persuasive.)
>
> Yeah, I agree the forward declarations are not ideal (and the clang file
> did raise my eyebrows when I first saw it), but after a while I started
> to like it.
>
> FWIW, I wouldn't be opposed to just #including the relevant files
> instead of forward-declaring stuff, but I think doing it the same way is
> better for consistency.
>
>
> Out of interest, I took a look at what lld is doing. I've found that
> while it doesn't have a LLVM.h equivalent, it is a heavy user of "using
> namespace llvm" (about 2 out of 3 cpp files have it). This approach
> wouldn't work that well for us because of naming conflicts ("Module"),
> and I would consider it inferior for the same reason that "using
> namespace std" is discouraged -- it just brings in too much stuff into
> your scope.
>
> regards,
> pl
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

[Adrian McCarthy via lldb-dev]

I don't have a strong opinion, but I lean against the idea for two reasons:

1.  The `llvm::` prefixes don't really hinder readability for me.  They're
like `std::` prefixes on all the C++ standard library types, which I'm
perfectly happy to type and read--moreso than using declarations.  Sure,
anybody who's been here a while knows which classes come from LLVM, but new
folks might build that knowledge by seeing the prefixes.

2.  I'm not a fan of forward declaring types provided by other parts of the
code, as it requires intimate knowledge of implementation details.  In
practice this may not matter much for the types we're considering.  If it
grew more widespread, however, I'd be more concerned.  (Somewhere I've
written a long explanation of this opinion.  I'll go search for it if
anyone cares.  The Google style guide discourages forward declarations, but
the rationale given there isn't as persuasive.)

On Wed, Apr 17, 2019 at 4:18 PM Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hey Pavel,
>
> Sounds like a good idea. I don't have a strong opinion on this matter, but
> I'm always in favor of improving readability.
>
> Cheers,
> Jonas
>
> On Wed, Apr 17, 2019 at 3:38 AM Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hello all,
>>
>> some llvm classes, are so well-known and widely used, that qualifying
>> them with "llvm::" serves no useful purpose and only adds visual noise.
>> I'm thinking here mainly of ADT classes like String/ArrayRef,
>> Optional/Error, etc. I propose we stop explicitly qualifying these
>> classes.
>>
>> We can implement this proposal the same way as clang solved the same
>> problem, which is by creating a special LLVM.h
>> <
>> https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/LLVM.h>
>>
>> header in the Utility library. This header would adopt these classes
>> into the lldb_private namespace via a series of forward and "using"
>> declarations.
>>
>> I think clang's LLVM.h is contains a well-balanced collection of adopted
>> classes, and it should cover the most widely-used classes in lldb too,
>> so I propose we use that as a starting point.
>>
>> What do you think?
>>
>> regards,
>> pavel
>>
>> PS: I'm not proposing any wholesale removal of "llvm::" qualifiers from
>> these types, though I may do some smaller-scale removals if I'm about to
>> substantially modify a file.
>> ___
>> 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] Symbol Server for LLDB

[Adrian McCarthy via lldb-dev]

Not currently (at least, not for the platforms I use primarily), but there
is definitely interest in a symbol fetcher so there may be somebody working
on it.

On Sun, Mar 24, 2019 at 11:11 PM Murali Venu Thyagarajan via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hello,
>
> Is there a way to setup a symbol server for lldb just like how I could
> setup a centralized and indexed symbol server for Windbg. Please let me
> know.
>
> Thanks,
> Murali
> ___
> 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

[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] RFC: Eliminate LLDB_DISABLE_PYTHON

[Adrian McCarthy via lldb-dev]

OK, thanks all for the discussion.

I'll try to fix the immediate problems (the build breakage and the Python
detection).  If I get more ambitious, I'll make another proposal.

On Thu, Mar 7, 2019 at 12:55 PM Zachary Turner  wrote:

> Yes, Pavel pointed out one specific case where it is used, and that case
> definitely needs to be supported.
>
> We've talked in the past about fixing the layering in such a way that all
> Python related code is in ScriptInterpreterPython, but there's definitely a
> non-trivial amount of work needed to make that possible.  And I agree, if
> that were the case today, then you could just turn it off trivially.
>
> On Thu, Mar 7, 2019 at 12:48 PM Jim Ingham  wrote:
>
>>
>>
>> > On Mar 7, 2019, at 11:37 AM, Zachary Turner  wrote:
>> >
>> >
>> >
>> > On Thu, Mar 7, 2019 at 11:03 AM Jim Ingham via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> > Even though you can just use debugserver/lldb-server and debug
>> remotely, many people find it handy to be able to run a debugger directly
>> on the device they are using.  But requiring that you port Python and
>> bundle it with your embedded platform just to get a debugger there is a
>> pretty big ask.  So it is still quite useful to be able to build lldb
>> without Python.  This option hasn't been broken all that frequently in our
>> uses, but if it is being a problem, the better solution would be to set up
>> a bot to build with this option, so we can make sure it keeps working.
>> >
>> > That's true, but there's a maintenance burden associated with this
>> handiness, and if nobody uses it that much (or at all?), it's better IMO to
>> optimize for low maintenance.  Every time I've tried this configuration it
>> has been broken, which leads me to believe that in practice nobody is
>> actually using it.  If that really is the case, I'd rather it be gone.  I
>> don't think we should keep code around just in case, without specific
>> evidence that it's providing value.
>>
>>
>> It does get used, though we might be able to get away from that at some
>> point.  But I still think requiring any new platform that might want to run
>> a debugger to get Python up first is unfortunate, and we shouldn't lightly
>> require it.
>>
>> But also, this isn't just about Python in particular.  Everything in lldb
>> that touches the script interpreter should be going through the abstract
>> ScriptInterpreter class.  The only place where the fact that the script
>> interpreter happens to be Python should show up is in the
>> ScriptInterpreterPython.  So building without Python should be as simple as
>> not building the ScriptInterpreterPython and not initializing that plugin.
>> The maintenance burden for this option should be trivial.  Something is
>> broken that LLDB_DISABLE_PYTHON has gotten entangled deeper in lldb.  I'd
>> much prefer we fix that.
>>
>> It would be really cool, for instance, if lldb could support a Python2
>> and a Python3 script interpreter to ease the transition for folks with lots
>> of legacy Python 2 code (such folks exist).  lldb was designed to support
>> that sort of thing.
>>
>> Or maybe at some point we should support some other new hotness
>> language.  I'm not sure it is good to bind ourselves inextricably to Python.
>>
>> Jim
>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] RFC: Eliminate LLDB_DISABLE_PYTHON

[Adrian McCarthy via lldb-dev]

We have a build option to build LLDB without Python.  This option is
automatically set if Cmake can't find or "validate" your Python
distribution.

Since LLDB is rarely built with this option, nobody discovers when this
configuration breaks.  For example, if you try it today, you'll get a
handful of missing symbol errors because their declarations are #if'ed out
but other code still references them.

I'm proposing eliminating this option and fixing the validation of the
Python distribution in LLDBConfig.cmake.

If you believe LLDB_DISABLE_PYTHON is still useful, please speak up, and
I'll instead look at fixing the existing build problems.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Do we have any infrastructure for creating mini dump files from a loaded process or from a core file?

[Adrian McCarthy via lldb-dev]

Zach's right.  On Windows, lldb can produce a minidump, but it just calls
out to a Microsoft library to do so.  We don't have any platform-agnostic
code for producing a minidump.

I've also pinged another Googler who I know might be interested in
converting between minidumps and core files (the opposite direction) to see
if he has any additional info.  I don't think he's on lldb-dev, though, so
I'll act as a relay if necessary.

On Wed, Jun 13, 2018 at 12:07 PM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> We can’t produce them, but you should check out the source code of google
> breakpad / crashpad which can.
>
> That said it’s a pretty simple format, there may be enough in our consumer
> code that should allow you to produce them
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Proposal: Using LLD in tests

[Adrian McCarthy via lldb-dev]

>  (it seems the "native" pdb reading apis in llvm are not all implemented)

Sorry, I missed this thread earlier.  That's true, the native PDB reading
APIs have been started but are not complete.  I'm working on that, mostly
in the context of llvm-pdbutil rather than lldb.

On Tue, May 1, 2018 at 9:14 AM, Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I have created a patch , which extends
> lldb-test to support more precise dumping of the symbol information in a
> module. It uses lld to make sure the tests can run on any system (which has
> lld checked out) and to avoid the tests being affected by the environment.
> Let me know what you think of it.
>
> I've also tried using lld for the PDB tests. The lld part worked fine, but
> unfortunately, it seems lldb still depends on the microsoft pdb reader to
> get the symbol information (it seems the "native" pdb reading apis in llvm
> are not all implemented).
>
> On the bright side, it looks like it should be able to produce working (and
> debuggable) MachO binaries using lld. It probably does not support all the
> fancy features that the native darwin linker does, but it seemed to work
> fine for my hello world examples (the only issue I saw was that it is not
> possible to convince it to *not* require the dyld_stub_binder symbol, but
> this can be worked around). I am going to continue experimenting here.
>
>
> On Thu, 19 Apr 2018 at 19:41, Ted Woodward 
> wrote:
>
>
> > Our Windows buildbots use msys for gnuisms. The makefiles in the test
> suite run fine with minimal modifications (just the object delete hack Zach
> put in to use del instead of rm; msys make doesn't accept cmd syntax while
> Cygwin make does). Now, that's using clang to build Hexagon binaries, but
> teaching the makefile to use cl syntax shouldn't be too hard. I've seen it
> done before; same makefile for windows and various unix derivatives, detect
> what OS you were running on and set CFLAGS/CXXFLAGS/LDFLAGS accordingly.
>
> > Ted
>
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
> > > -Original Message-
> > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
> Pavel
> > > Labath via lldb-dev
> > > Sent: Thursday, April 19, 2018 12:45 PM
> > > To: Leonard Mosescu 
> > > Cc: aaron.lee.sm...@gmail.com; LLDB 
> > > Subject: Re: [lldb-dev] Proposal: Using LLD in tests
> > >
> > > On Thu, 19 Apr 2018 at 18:19, Leonard Mosescu 
> > > wrote:
> > >
> > > >>the PDB tests under lit/SymbolFile/PDB need a linker to produce
> > > >> the
> > > program database
> > >
> > >
> > > > With this proposal, would we preserve any coverage for MSVC produced
> > > debug information?
> > >
> > >
> > > Well.. the question there is what are you trying to test? Is it the
> fact your
> > > debugger works with a particular compiler+linker combination (note that
> those
> > > tests already compile with clang-cl), or that your pdb-parsing code is
> sane.
> > > (integration vs. regression test).
> > >
> > > Historically we've only had the former kind of tests (dotest), and
> we've had the
> > > ability (and used it) to run those tests against different kinds of
> compilers. This
> > > is all nice, but it means that a specific test will be testing a
> different thing for
> > > every person who runs it. That's why I would like to build up a suite
> of more
> > > regression-like tests (*). I would say that the tests under lit/***
> should be
> > > regression tests and our goal should be to remove as many system
> > > dependencies as possible, and leave the job of testing integration with
> a
> > > specific toolchain to "dotest" tests (**).
> > >
> > > Technically, the answer to your question is "no", because currently
> dotest tests
> > > don't know how to work with cl+link. Making that work would be an
> interesting
> > > project (although a bit annoying as the Makefiles are full of
> gcc-isms).
> > > However, I don't think that should stop us here.
> > >
> > > (*) Ideally I would like to leave even the compiler out of the equation
> for these
> > > tests, and make it so that the tests always run on the exact same set
> of bytes. I
> > > am hoping I will be able to write at least some tests using .s files.
> However, I
> > > don't think I will do that for all of them, because these files can be
> > > long/verbose/tedious to write.
> > >
> > > (**) However, even "dotest" tests should have a "default" mode which is
> as
> > > hermetic as possible.
> > > ___
> > > lldb-dev mailing list
> > > lldb-dev@lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev m

Re: [lldb-dev] problems running the LLDB lit tests on Windows

[Adrian McCarthy via lldb-dev]

If I run the llvm lit tests with the debug build of Python, I get the same
kind of errors, so I think this is a bug in lit that we haven't seen
because people have been using it with non-debug Python.  I'm investigating
that angle.

On Fri, Apr 20, 2018 at 12:21 PM, Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> See my comment in https://reviews.llvm.org/D45333 .
>
>
>
> r330275 changed how lldb’s lit tests were set up. This gives cmake errors
> using the Visual Studio generator; I wouldn’t be surprised if what you’re
> seeing using ninja is the same issue.
>
>
>
> Short version: the cmake code that sets up the lit config in lldb is
> different from the cmake code that sets up the lit config in clang. This is
> causing the VS generator errors, and might be causing your problems with
> ninja.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] *On Behalf Of 
> *Adrian
> McCarthy via lldb-dev
> *Sent:* Friday, April 20, 2018 1:21 PM
> *To:* LLDB 
> *Subject:* [lldb-dev] problems running the LLDB lit tests on Windows
>
>
>
> I'm trying to figure out what's happening with the LLDB lit tests on
> Windows.  I'm not sure how to proceed with debugging this.
>
>
>
> I execute this command:
>
>
>
>   ninja check-lldb
>
>
>
> And several things happen very rapidly:
>
>
>
> 1.  On the console, I get one warning that says:
>
>
>
> D:/src/llvm/mono/llvm-project/llvm\utils\lit\lit\discovery.py:121:
> ResourceWarning: unclosed file <_io.BufferedReader name=3>
>
> key = (ts, path_in_suite)
>
>
>
> 2.  Then I get several dozen messages of this form:
>
>
>
> D:/src/llvm/mono/llvm-project/llvm\utils\lit\lit\TestRunner.py:727:
> ResourceWarning: unclosed file <_io.BufferedReader name=6>
>
> res = _executeShCmd(cmd.rhs, shenv, results, timeoutHelper)
>
>
>
> 3.  I get more than 200 dialog boxes that are essentially assertion
> failures in the CRT implementation of `close`.  The line complained about
> in the dialog is:
>
>
>
> _VALIDATE_CLEAR_OSSERR_RETURN((fh >= 0 && (unsigned)fh <
> (unsigned)_nhandle), EBADF, -1);
>
>
>
> where `fh` is the value passed to `close`.  Indeed, `fh` typically has a
> value like 452 which is not in the range of 0 to `_nhandle` because
> `_nhandle` is 64.
>
>
>
> Starting from 3, I tried to walk up the stack to see what's going on, but
> it's just the generic workings of the Python virtual machine.  The `close`
> call is happening because something in the .py code is calling `close`.
> It's hard to see the Python code in the debugger.  It doesn't actually seem
> to be test code.
>
>
>
> So I checked out the command line for one of those asserting processes to
> see if I could figure out which tests are exhibiting the problem.
>
>
>
> "C:\python_35\python_d.exe" "-R" "-c" "from multiprocessing.spawn import
> spawn_main; spawn_main(pipe_handle=992, parent_pid=32640)"
> "--multiprocessing-fork"
>
>
>
> The `pipe_handle` value does not correspond to the value being passed to
> the `close`.  The `parent_pid` always refers to the parent lit command.
>
>
>
> There always seem to be 32 Python processes in this state.  If I kill one,
> another is immediately spawned to replace it (creating a new assertion
> failure dialog).  I'm guessing that if I continued, there would be one for
> each test, and that somewhere there's a limit of 32 processes at a time.
>
>
>
> So this kind of sounds like a lit bug, but other lit tests (as in `ninja
> check-llvm`) run just fine.  So it has something to do with how we invoke
> lit for LLDB.  The command being executed, per the build.ninja file, is:
>
>
>
> cd /D D:\src\llvm\build\mono\tools\lldb\lit && C:\python_35\python_d.exe
> D:/src/llvm/build/mono/./bin/llvm-lit.py -sv --param
> lldb_site_config=D:/src/llvm/build/mono/tools/lldb/lit/lit.site.cfg
> --param 
> lldb_unit_site_config=D:/src/llvm/build/mono/tools/lldb/lit/Unit/lit.site.cfg
> D:/src/llvm/build/mono/tools/lldb/lit
>
>
>
> The LLDB-specific things in the command are lit configs, with which I've
> been blissfully ignorant.  Should I head down that rabbit hole?  Could this
> be a problem with my environment?
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] problems running the LLDB lit tests on Windows

[Adrian McCarthy via lldb-dev]

I'm trying to figure out what's happening with the LLDB lit tests on
Windows.  I'm not sure how to proceed with debugging this.

I execute this command:

  ninja check-lldb

And several things happen very rapidly:

1.  On the console, I get one warning that says:

D:/src/llvm/mono/llvm-project/llvm\utils\lit\lit\discovery.py:121:
ResourceWarning: unclosed file <_io.BufferedReader name=3>
key = (ts, path_in_suite)


2.  Then I get several dozen messages of this form:

D:/src/llvm/mono/llvm-project/llvm\utils\lit\lit\TestRunner.py:727:
ResourceWarning: unclosed file <_io.BufferedReader name=6>
res = _executeShCmd(cmd.rhs, shenv, results, timeoutHelper)


3.  I get more than 200 dialog boxes that are essentially assertion
failures in the CRT implementation of `close`.  The line complained about
in the dialog is:


_VALIDATE_CLEAR_OSSERR_RETURN((fh >= 0 && (unsigned)fh <
(unsigned)_nhandle), EBADF, -1);


where `fh` is the value passed to `close`.  Indeed, `fh` typically has a
value like 452 which is not in the range of 0 to `_nhandle` because
`_nhandle` is 64.

Starting from 3, I tried to walk up the stack to see what's going on, but
it's just the generic workings of the Python virtual machine.  The `close`
call is happening because something in the .py code is calling `close`.
It's hard to see the Python code in the debugger.  It doesn't actually seem
to be test code.

So I checked out the command line for one of those asserting processes to
see if I could figure out which tests are exhibiting the problem.

"C:\python_35\python_d.exe" "-R" "-c" "from multiprocessing.spawn import
spawn_main; spawn_main(pipe_handle=992, parent_pid=32640)"
"--multiprocessing-fork"


The `pipe_handle` value does not correspond to the value being passed to
the `close`.  The `parent_pid` always refers to the parent lit command.

There always seem to be 32 Python processes in this state.  If I kill one,
another is immediately spawned to replace it (creating a new assertion
failure dialog).  I'm guessing that if I continued, there would be one for
each test, and that somewhere there's a limit of 32 processes at a time.

So this kind of sounds like a lit bug, but other lit tests (as in `ninja
check-llvm`) run just fine.  So it has something to do with how we invoke
lit for LLDB.  The command being executed, per the build.ninja file, is:

cd /D D:\src\llvm\build\mono\tools\lldb\lit && C:\python_35\python_d.exe
D:/src/llvm/build/mono/./bin/llvm-lit.py -sv --param
lldb_site_config=D:/src/llvm/build/mono/tools/lldb/lit/lit.site.cfg --param
lldb_unit_site_config=D:/src/llvm/build/mono/tools/lldb/lit/Unit/lit.site.cfg
D:/src/llvm/build/mono/tools/lldb/lit


The LLDB-specific things in the command are lit configs, with which I've
been blissfully ignorant.  Should I head down that rabbit hole?  Could this
be a problem with my environment?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] postmortem debugging (core/minidump) & modules

[Adrian McCarthy via lldb-dev]

On Tue, Apr 10, 2018 at 3:12 PM, Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
>
> On Apr 10, 2018, at 2:30 PM, Leonard Mosescu  wrote:
>
> Thanks Greg! It makes sense and looking at the code it's already
> implemented along those lines: Target::GetSharedModule() defaults to
> Platform::GetSharedModule() if the initial attempt to get the module fails.
>
> The part I'd like to understand is if there's a precedence for modules
> which don't have any accessible file image (local or remote). Is everything
> expected to work if we create placeholder Module & ModuleSpecs?
>
>
> No, it is up to the platform to be able to track down files that don't
> exist locally. Most platforms do nothing and will return an empty module
> shared pointer. We need a file to use or we will just not have any info.
>

Just to make sure I understand:  we need a file with the debug info (e.g.,
a PDB), but we shouldn't need the actual executable/shared library/DLL file
except on platforms where the debug info is embedded in the binary.  Right?


>
> (it seems that the current implementation assumes that we have a file
> somewhere. Ex. even creating a Module from a ModuleSpec will still try to
> map the source ModuleSpec to some files).
>
>
> Yes. Right now with only the path, we will load the file if it exists on
> disk since no UUID was specified in the ModuleSpec which is really bad and
> can lead to incorrect info being displayed.
>
>
> At Apple, we call "dsymForUUID " which, if global defaults were set
>> to point at Apple's build servers, would go out and download the correct
>> file for us and store it locally in a cache for future use.
>
>
> Just curious, what happens if the download fails? Is the corresponding
> module skipped? (is this strictly about the dSYMs or the same mechanism
> works for the Mach-O binaries?)
>
>
> It will block until the module is downloaded, and it can and often does
> fail and returns an error that can be displayed. When we need to download
> large debug info files, it creates delays with no user interaction and
> often leads to people wondering what is going on. Not optimal, but it does
> work if you wait for it.
>
>
> That way if you create a target that is a minidump on a different system
>> (macOS, linux, etc), the platform would be remote-windows.
>>
>
> Not sure if I understand this one, core & minidumps are currently not
> using any of the the remote debugging machinery, right? Are you suggesting
> changing that?
>
>
> No. Each binary knows how to tell LLDB what target triple it is. PECOFF
> files will always map to the host windows platform or remote-windows when
> not on a Windows host computer. If you say "file a.out" and give it a
> PECOFF file, just do "target list" and see the platform was selected for
> you. Since the Minidump is specific to Windows, it should select the right
> platform for you. If it doesn't we will need to fix that.
>
> Does the mini dump format have the UUID or some sort of checksum of the
> file in it?
>
>
> On Tue, Apr 10, 2018 at 11:56 AM, Greg Clayton  wrote:
>
>>
>>
>> On Apr 10, 2018, at 11:32 AM, Leonard Mosescu via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> I'm looking at how the LLDB minidump reader creates the list of modules:
>>
>> void ProcessMinidump::ReadModuleList() {
>>
>> ...
>>
>> const auto file_spec = FileSpec(name.getValue(), true);
>> ModuleSpec module_spec = file_spec;
>> Status error;
>> lldb::ModuleSP module_sp = GetTarget().GetSharedModule(module_spec, &
>> error);
>> if (!module_sp || error.Fail()) {
>> continue;
>> }
>>
>> ...
>>
>> }
>>
>>
>> LLDB currently will insist on finding a local image for the module, which
>> is usually not the case for postmortem debugging on machines different than
>> the the the one where the minidump was created.
>>
>> I don't see an obvious way to model modules which have no local image
>> (which is still different than the remote scenario where there is a remote
>> module image), am I missing anything?
>>
>>
>> The lldb_private::Platform is responsible for digging up any binaries for
>> a given target, so this code should be grabbing the platform from the
>> target and using that to get the shared module. That way if you create a
>> target that is a minidump on a different system (macOS, linux, etc), the
>> platform would be remote-windows.
>>
>> That being said "ModuleSpec" should be filled in with more than just the
>> path. It should specify the UUID info from the mini dump that specifies
>> exactly which version the file that you want. That way if the file on the
>> current system exists, it won't return it unless the path matches. I assume
>> the mini dump has each module's UUID information? If so, set it. If not the
>> file format assumes you will be running the dumping the same machine and it
>> should be updated to include this information. The platform code can then
>> use this UUID info to possible go and fetch the right version from a UUID
>> database, or how ever the pl

Re: [lldb-dev] Virus in a test file?

[Adrian McCarthy via lldb-dev]

It's several tests that use this input.  Perhaps rebuilding it with
clang-cl and lld-link would change it enough to appease the virus scanner.

On Fri, Apr 6, 2018 at 10:59 AM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Best thing I can think of is to delete this test.  This has come up
> several times on the list.  The reason the executable is checked in is
> because otherwise we can't run the test on non-Windows.  But given that
> this keeps occurring, maybe we should just get rid of the test.
>
> On Fri, Apr 6, 2018 at 10:57 AM via lldb-dev 
> wrote:
>
>> I'm setting up on a new Windows PC, and after cloning the monorepo
>> my virus scanner decided to delete a test input file:
>>
>> lldb/unittests/SymbolFile/PDB/Inputs/test-pdb.exe
>>
>> citing "RDN/Generic.cpt" as the reason.
>>
>> If this is really necessary, I can probably work out how to persuade
>> the scanner to ignore this file, but I figured I should ask first.
>> Thanks,
>> --paulr
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Current state of the unit tests

[Adrian McCarthy via lldb-dev]

Actually, it appears one of the lit tests is unexpectedly passing:

Unexpected Passing Tests (1):
lldb :: Expr/TestCallStdStringFunction.test

lit then returns an error code, and ninja bails before starting the
dotest.py tests:

FAILED: cmd.exe /C "cd /D D:\src\llvm\build\mono\tools\lldb\lit &&
C:\python_35\python_d.exe D:/src/llvm/build/mono/./bin/llvm-lit.py -sv
--param lldb_site_config=D:/src/llvm/build/mono/tools/lldb/lit/lit.site.cfg
--param
lldb_unit_site_config=D:/src/llvm/build/mono/tools/lldb/lit/Unit/lit.site.cfg
D:/src/llvm/build/mono/tools/lldb/lit"
ninja: build stopped: subcommand failed.

I'm also seeing windows appear and quickly vanish a several times while
running the lit tests.

On Fri, Feb 23, 2018 at 4:15 PM, Vedant Kumar  wrote:

> check-lldb-lit should just be a dependency of check-lldb, so the dotest.py
> tests should still run.
>
> Are one of the lit tests failing? That might explain why subsequent tests
> aren't run.
>
> vedant
>
> On Feb 23, 2018, at 4:13 PM, Adrian McCarthy  wrote:
>
> As of this afternoon, it seems ninja check-lldb runs *only* the lit tests
> and not the dotest.py tests.  Was this an intentional change?
>
> On Fri, Feb 23, 2018 at 3:36 PM, Vedant Kumar via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Cool, I'll work up a patch for this.
>>
>> And thanks for commenting on PR36494, I'm testing a fix out right now :).
>>
>> vedant
>>
>> On Feb 23, 2018, at 3:35 PM, Pavel Labath  wrote:
>>
>> On 23 February 2018 at 15:17, Vedant Kumar  wrote:
>>
>> Second, TestClient::SendMessage is generating quite a lot of "INFO"
>> output which clutters up the terminal. Pavel, would you mind if I removed
>> this logging?
>>
>>
>> Yeah, we should probably do that. The idea here was that the packet
>> log would provide you with additional context for the situation when
>> the test fails, but it *is* very verbose. I'll have to come up with a
>> better solution for error reporting here.
>>
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Current state of the unit tests

[Adrian McCarthy via lldb-dev]

As of this afternoon, it seems ninja check-lldb runs *only* the lit tests
and not the dotest.py tests.  Was this an intentional change?

On Fri, Feb 23, 2018 at 3:36 PM, Vedant Kumar via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Cool, I'll work up a patch for this.
>
> And thanks for commenting on PR36494, I'm testing a fix out right now :).
>
> vedant
>
> On Feb 23, 2018, at 3:35 PM, Pavel Labath  wrote:
>
> On 23 February 2018 at 15:17, Vedant Kumar  wrote:
>
> Second, TestClient::SendMessage is generating quite a lot of "INFO" output
> which clutters up the terminal. Pavel, would you mind if I removed this
> logging?
>
>
> Yeah, we should probably do that. The idea here was that the packet
> log would provide you with additional context for the situation when
> the test fails, but it *is* very verbose. I'll have to come up with a
> better solution for error reporting here.
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] hashing pointers to strings

[Adrian McCarthy via lldb-dev]

If it's dead code, that certainly simplifies things!  I've sent a patch for
review to remove the unused, untested code.

https://reviews.llvm.org/D43202



On Mon, Feb 12, 2018 at 1:52 AM, Pavel Labath  wrote:

> [ Clang's emission of pubnames/pubtypes is controlled by the "debugger
> tuning" parameter. With -glldb they don't get emitted, with -ggdb,
> they do. (-glldb is default on mac, -ggdb elsewhere). In dwarf5 these
> sections have been dropped in favour of the new .debug_names section.
> ]
>
> On 10 February 2018 at 02:25, Jim Ingham via lldb-dev
>  wrote:
> > A quick glance indicates that this is all dead code.  I can't see
> anything that actually instantiates either of the pubnames classes.
> >
> > The DWARF pubnames tables were a previous attempt at producing DWARF
> indexes, but they didn't contain enough information to actually forstall
> deep dives into the DWARF, so they weren't actually useful.  clang doesn't
> emit them on macOS for sure, does it emit them on linux?  They are
> superseded by the new DWARF 5 accelerator tables, and I couldn't find any
> reference to pubnames in the DWARF 5 draft standard.
> >
> > We should check with Greg about this, but I don't think we're ever
> likely to get any use out of DWARF pubnames tables.  We should just delete
> this code.
> >
> > Jim
> >
> >
> >> On Feb 9, 2018, at 4:35 PM, Adrian McCarthy via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> DWARFDebugPubnamesSet.h has a type definition like this:
> >>
> >>   typedef std::unordered_multimap >>   std::hash,
> >>   CStringEqualBinaryPredicate>
> >>   cstr_to_index_mmap;
> >>
> >> In particular, note that the hasher will hash the pointer rather than
> the string it points to.
> >>
> >> It looks like this mostly works because the map is built once from
> string pointers that don't appear to be changed during the lifetime of the
> multimap.  That's fragile, and I'm not sure it's really working in all
> cases.  For example, there could be two different pointers to identical
> strings--since this is a multimap rather than a map, I assume we'd want
> those values merged under the same key, but since the pointers are
> distinct, they won't be.
> >>
> >> I'd like to change the key to a std::string or a StringRef for
> correctness and robustness, but that'll likely be a tad slower because
> hashing variable-length strings is more work than hashing fixed-length
> pointers.  (I don't think it'll change comparisons much, since the
> comparator is checking the strings.)
> >>
> >> Objections or better suggestions?
> >>
> >> It's also hard for me to test, as most of the LLDB DWARF tests are
> still broken on Windows because the inferiors are generated with CodeView
> rather than DWARF.  I'm working on that, but it'll take changes to the
> lld-link driver.
> >>
> >> Adrian.
> >> ___
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] hashing pointers to strings

[Adrian McCarthy via lldb-dev]

DWARFDebugPubnamesSet.h has a type definition like this:

  typedef std::unordered_multimap,
  CStringEqualBinaryPredicate>
  cstr_to_index_mmap;

In particular, note that the hasher will hash the *pointer *rather than the
string it points to.

It looks like this mostly works because the map is built once from string
pointers that don't appear to be changed during the lifetime of the
multimap.  That's fragile, and I'm not sure it's really working in all
cases.  For example, there could be two different pointers to identical
strings--since this is a multimap rather than a map, I assume we'd want
those values merged under the same key, but since the pointers are
distinct, they won't be.

I'd like to change the key to a std::string or a StringRef for correctness
and robustness, but that'll likely be a tad slower because hashing
variable-length strings is more work than hashing fixed-length pointers.
(I don't think it'll change comparisons much, since the comparator *is
*checking
the strings.)

Objections or better suggestions?

It's also hard for me to test, as most of the LLDB DWARF tests are still
broken on Windows because the inferiors are generated with CodeView rather
than DWARF.  I'm working on that, but it'll take changes to the lld-link
driver.

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

[lldb-dev] FYI: LLDB DWARF tests on Windows are broken

[Adrian McCarthy via lldb-dev]

It looks like tests of DWARF-specific functionality on Windows are failing
because we're actually generating CodeView in a PDB rather than DWARF.

For example, TestSignedTypes.py fails for reasons completely unrelated to
whether the types are signed or not.  Apparently DWARF and CodeView
consider the bounds of the live range for the variables to be slightly
different.  When using CodeView info, there's a `thread step-over` command
that takes you just outside the scope block, so the subsequent `frame
variable` command fails to produce the expected output.

The makefile creates compile steps with `-g` and link steps with
`-fuse-lld`, so you'd expect DWARF, but, due to recent changes in clang and
lld, this will actually produce CodeView/PDB when building for Windows.

I'll look into a fix tomorrow.  I'm told it might involve not only tweaking
the makefile flags for these tests, but also ensuring that the clang driver
passes the right flags to lld.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Bug 34676] check-lldb target fails on Windows due to incomplete compiler path

[Adrian McCarthy via lldb-dev]

I haven't spent too much time in LLDB lately.  The number of failures you
see seems a little high.  On Windows 7, I get:

===
Test Result Summary
===
Test Methods:   1301
Reruns:   28
Success: 387
Expected Failure:237
Failure:   4
Error:11
Exceptional Exit:  0
Unexpected Success:3
Skip:659
Timeout:   0
Expected Timeout:  0


On Tue, Sep 26, 2017 at 5:31 AM, Carlos Alberto Enciso <
international.phan...@gmail.com> wrote:

> Hi Adrian,
>
> As you are working on the above Windows issue, I am assuming you are
> running LLDB on Windows.
> I have managed to build LLDB on Windows 10, after getting the correct
> dependencies.
>
> But from the LLDB home page, it seems that LLDB is only built and no tests
> are run:
>
>- LLDB Windows Server 2008 x86 (CMake, MSVS 2013, Windows SDK 8.1, no
>tests) 
>- LLDB Windows 7 x86 (CMake, MSVS 2013, Windows SDK 8.1, no tests)
>
>
> I run the tests via 'check-lldb' and these are the results:
>
> 63>  ===
>
> 63>  Test Result Summary
>
> 63>  ===
>
> 63>  Test Methods:   1299
>
> 63>  Reruns:   68
>
> 63>  Success: 365
>
> 63>  Expected Failure:233
>
> *63>  Failure:  34*
>
> 63>CUSTOMBUILD : error : 14
>
> 63>  Exceptional Exit:  0
>
> *63>  Unexpected Success:5*
>
> 63>  Skip:648
>
> 63>  Timeout:   0
>
> 63>  Expected Timeout:  0
>
> I am wondering if these results match yours.
>
> Thanks very much,
>
> Carlos Enciso
>
> On Tue, Sep 19, 2017 at 11:08 PM, via lldb-dev 
> wrote:
>
>> Adrian McCarthy  changed bug 34676
>> 
>> What Removed Added
>> Assignee lldb-dev@lists.llvm.org amcca...@google.com
>>
>> *Comment # 1  on bug
>> 34676  from Adrian McCarthy
>>  *
>>
>> I'm starting with git bisect to see if I can pinpoint when this got broken.  
>> It
>> looks like it may have been a while back already.
>>
>> --
>> You are receiving this mail because:
>>
>>- You are the assignee for the bug.
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] PDB symbol reader status?

[Adrian McCarthy via lldb-dev]

Basic PDB support is in LLDB if you're running on Windows.  LLDB has a
SymbolFilePDB plugin that relies on a PDB abstraction in LLVM.  There is
currently just one implementation of that abstraction, and it relies on
DIA, which is a Microsoft-provided DLL on Windows for looking up
information in a PDB.

I'm currently working on a native PDB reader that implements the same
interface without reliance on DIA, so that should eventually provide the
same functionality even if you're not running on Windows.

Browsing through the PDB plugin in LLDB, I see a lot of "//TODO:  Implement
this" methods, so you won't (yet) have rich type information.  But you can
set breakpoints by name, get a stack backtrace, print variable values, etc.


On Wed, Jul 26, 2017 at 11:19 AM, Vadim Chugunov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
> What is the current status of LLDB's PDB file parser on Windows?   It was
> announced back in 2015 that PDB support is coming soon, so I was wondering
> where it's at currently.
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Adrian McCarthy via lldb-dev]

>  [UCRT] had been pushed to Vista, 7 and 8 via Windows Update

I didn't think that was true in general.  One of the redist options is to
include an MSU in your installer that tells Windows Update to add UCRT to
the list of components it updates.  So some Vista, 7, and 8 users may have
received it via Windows Update, but probably not all.

That's what all the deployment articles seem to suggest (assuming I've
understood them correctly).  I suppose they may have decided to ship UCRT
to pre-Windows 10 users anyway, but I haven't come across anything that
says that.

On Wed, Jan 11, 2017 at 6:48 PM, Vadim Chugunov  wrote:

>
>
> On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner 
> wrote:
>
>> Ahh, that would make sense as well, since LLDB links against liblldb as a
>> dll.  Don't see a good solution to this short of forcing dynamic linking.
>>  liblldb has to be a dll because it needs to be visible to python as an
>> extension module.  And if it's a dll and uses static linking, then we would
>> have to require that lldb.exe not pass file handles across the dll
>> boundary.  If that's easy then great, but I suspect it probably isn't.
>>
>> Honestly dynamic linking was created to solve exactly these kinds of
>> problems.  Yes there's the redist issue if on Windows < 10, but it seems
>> like a small price to pay for something that doesn't have weird subtle
>> bugs.  And as time goes on, more and more people will be on windows 10
>> anyway.
>>
>> Does the redistributable issue present a challenge for your use case?
>>
>
> There are actually two part of the MSVC runtime: the Universal C Runtime
> (UCRT) and the compiler-specific, VCRUNTIME140.   The former is widely
> available (comes with Windows 10, and had been pushed to Vista, 7 and 8 via
> Windows Update).  The latter is tied to the compiler version and must still
> be redistributed with programs.   Ideally, LLDB would use dynamic UCRT +
> static VCRUNTIMExx.  Unfortunately this doesn't seem to be a supported
> configuration (discussion of this issue in Python bug tracker
> ).   Looks like Python folks opted
> for shipping VCRUNTIME140.DLL in their install directory.
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Adrian McCarthy via lldb-dev]

I agree that linking to them dynamically is safer, but then you get into
the deployment problem.  You do have to redistribute the DLLs for users
using anything less than Windows 10.

There are several options for doing that:  VCRedist, MSMs, MSUs, and
app-local deployment.  They each have drawbacks.

On Wed, Jan 11, 2017 at 1:00 PM, Zachary Turner  wrote:

> If we do that though, we still get 2 copies of the CRT.  One for python
> and one for LLDB.  While I *think* there is a strong enough API boundary in
> how the application and Python access each others' data structures that it
> doesn't matter, I'm not 100% sure without further research.  It seems safer
> to link dynamically unless there is a strong reason not to.
>
> On Wed, Jan 11, 2017 at 12:41 PM Adrian McCarthy 
> wrote:
>
>> I was just reading up on this the other day.  Statically linking to the
>> Universal CRT (and related libraries) *is* supported though it's not
>> Microsoft's top recommendation.
>>
>> Initially, they said they weren't going to support app-local deployment,
>> but they backed off on that, and it, too, is now supported.
>>
>> Some details here:  https://blogs.msdn.microsoft.com/vcblog/2016/04/18/c-
>> runtime-deployment-why-choosing-applocal/
>>
>>
>> On Wed, Jan 11, 2017 at 10:51 AM, Reid Kleckner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> The purpose of linking the CRT statically was to ensure that clang can
>> run on systems that don't have the CRT already installed from some other
>> app or by VS itself. As long as that is preserved, feel free to do whatever
>> you need.
>>
>> I think we still want to link vcruntime140 statically and the C++ runtime
>> statically, for example.
>>
>> On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Is static CRT even still supported / recommended when using the new
>> Universal CRT?  My understanding is the new UCRT is considered a core
>> windows component, so we don't ahve to distribute redistributables
>> anymore.  Maybe I'm wrong about this.
>>
>> That said, I think we want dynamic regardless, otherwise we're back in
>> the same boat of user having to compile Python, which is the exact thing
>> 3.5+ is supposed to solve.  We should just always use dynamic so the user
>> doesn't have to do anything and it just works.
>>
>> On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov 
>> wrote:
>>
>> Sorry, just found another problem: the installed lldb crashes when given
>> a script via the command line.  For example, `lldb -O "p 42"` dies with
>> exception 0xC409.
>>
>> It didn't happen with the one I've build locally, so I started digging...
>> The difference seems to be that build_llvm_build_package.bat links CRT
>> statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the dynamic CRT.
>>
>> The crash kinda makes sense, because python35.dll links CRT dynamically,
>> so LLDB ends up with two copies of it in the process, which is known to
>> cause all sorts of trouble.
>>
>> Not sure what to do about this one, - you probably wanted static CRT to
>> avoid having to install MSVC redistributable?
>>
>>
>> On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov 
>> wrote:
>>
>> Yes, the new build works!
>>
>> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>>
>> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
>> Please let me know if that works.
>>
>> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
>> wrote:
>> > It sounds like the solution to the problem is to downgrade SWIG on the
>> build
>> > machine.  If it's using version 3.0.9 or higher, just use whatever the
>> last
>> > version before that is.  3.0.8, for example.
>> >
>> > At least there's a good workaround in the interim (i.e. setting
>> PYTHONPATH)
>> >
>> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
>> wrote:
>> >>
>> >> I'll do another snapshot maybe next week or the week after. You can
>> >> also ping me if you want it sooner or later.
>> >>
>> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
>> >> fully understand the problem here, but if there's some way to work
>> >> around it and get lldb into good shape for the 4.0.0 installer, that
>> >> would be great.
>> >>
>> >> Thanks,
>> >> Hans
>> >>
>> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
>> wrote:
>> >> > This appears to be a SWIG bug: https://github.com/swig/swig/
>> issues/769
>> >> >
>> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>> >> > wrote:
>> >> >>
>> >> >> It worked!
>> >> >>
>> >> >> ...but not before I set PYTHONPATH=C:\Program Files
>> >> >> (x86)\LLVM\lib\site-packages\lldb
>> >> >> Without that, it couldn't find the _lldb module, so we are not quite
>> >> >> out
>> >> >> of the woods yet.
>> >> >>
>> >> >> When are you planning to make the next snapshot build?
>> >> >> Thanks!
>> >> >>
>> >> >>
>> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>> >> >> wrote:
>> >> >>>
>> >> >>> Vadim, it looks like your change was committ

Re: [lldb-dev] Prebuilt binary for Windows

[Adrian McCarthy via lldb-dev]

I was just reading up on this the other day.  Statically linking to the
Universal CRT (and related libraries) *is* supported though it's not
Microsoft's top recommendation.

Initially, they said they weren't going to support app-local deployment,
but they backed off on that, and it, too, is now supported.

Some details here:
https://blogs.msdn.microsoft.com/vcblog/2016/04/18/c-runtime-deployment-why-choosing-applocal/


On Wed, Jan 11, 2017 at 10:51 AM, Reid Kleckner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> The purpose of linking the CRT statically was to ensure that clang can run
> on systems that don't have the CRT already installed from some other app or
> by VS itself. As long as that is preserved, feel free to do whatever you
> need.
>
> I think we still want to link vcruntime140 statically and the C++ runtime
> statically, for example.
>
> On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Is static CRT even still supported / recommended when using the new
>> Universal CRT?  My understanding is the new UCRT is considered a core
>> windows component, so we don't ahve to distribute redistributables
>> anymore.  Maybe I'm wrong about this.
>>
>> That said, I think we want dynamic regardless, otherwise we're back in
>> the same boat of user having to compile Python, which is the exact thing
>> 3.5+ is supposed to solve.  We should just always use dynamic so the user
>> doesn't have to do anything and it just works.
>>
>> On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov 
>> wrote:
>>
>>> Sorry, just found another problem: the installed lldb crashes when given
>>> a script via the command line.  For example, `lldb -O "p 42"` dies with
>>> exception 0xC409.
>>>
>>> It didn't happen with the one I've build locally, so I started
>>> digging... The difference seems to be that build_llvm_build_package.bat
>>> links CRT statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the
>>> dynamic CRT.
>>> The crash kinda makes sense, because python35.dll links CRT dynamically,
>>> so LLDB ends up with two copies of it in the process, which is known to
>>> cause all sorts of trouble.
>>>
>>> Not sure what to do about this one, - you probably wanted static CRT to
>>> avoid having to install MSVC redistributable?
>>>
>>>
>>> On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov 
>>> wrote:
>>>
>>> Yes, the new build works!
>>>
>>> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg 
>>> wrote:
>>>
>>> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
>>> Please let me know if that works.
>>>
>>> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
>>> wrote:
>>> > It sounds like the solution to the problem is to downgrade SWIG on the
>>> build
>>> > machine.  If it's using version 3.0.9 or higher, just use whatever the
>>> last
>>> > version before that is.  3.0.8, for example.
>>> >
>>> > At least there's a good workaround in the interim (i.e. setting
>>> PYTHONPATH)
>>> >
>>> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
>>> wrote:
>>> >>
>>> >> I'll do another snapshot maybe next week or the week after. You can
>>> >> also ping me if you want it sooner or later.
>>> >>
>>> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
>>> >> fully understand the problem here, but if there's some way to work
>>> >> around it and get lldb into good shape for the 4.0.0 installer, that
>>> >> would be great.
>>> >>
>>> >> Thanks,
>>> >> Hans
>>> >>
>>> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
>>> wrote:
>>> >> > This appears to be a SWIG bug: https://github.com/swig/swig/i
>>> ssues/769
>>> >> >
>>> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>>> >> > wrote:
>>> >> >>
>>> >> >> It worked!
>>> >> >>
>>> >> >> ...but not before I set PYTHONPATH=C:\Program Files
>>> >> >> (x86)\LLVM\lib\site-packages\lldb
>>> >> >> Without that, it couldn't find the _lldb module, so we are not
>>> quite
>>> >> >> out
>>> >> >> of the woods yet.
>>> >> >>
>>> >> >> When are you planning to make the next snapshot build?
>>> >> >> Thanks!
>>> >> >>
>>> >> >>
>>> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Vadim, it looks like your change was committed in r291291, and
>>> I've
>>> >> >>> built a new snapshot today which includes it. Can you give it a
>>> try
>>> >> >>> and see if everything works?
>>> >> >>>
>>> >> >>> Cheers,
>>> >> >>> Hans
>>> >> >>>
>>> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner <
>>> ztur...@google.com>
>>> >> >>> wrote:
>>> >> >>> > I will commit it, in the meantime can you request commit access
>>> so
>>> >> >>> > that
>>> >> >>> > any
>>> >> >>> > future patches you can commit?
>>> >> >>> >
>>> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov <
>>> vadi...@gmail.com>
>>> >> >>> > wrote:
>>> >> >>> >>
>>> >> >>> >> Thanks!
>>> >> >>> >>
>>> >> >>> >> Would anyone be so kind to commit that?
>>> >> >>> >>
>>> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zach

Re: [lldb-dev] logging in lldb

[Adrian McCarthy via lldb-dev]

On Wed, Jan 11, 2017 at 10:38 AM, Zachary Turner  wrote:

>
>
> On Wed, Jan 11, 2017 at 6:59 AM Pavel Labath  wrote:
>
>> Happy new year everyone. :)
>>
>> I have refreshed the implementation at
>>  with something more polished. I
>> consider this almost-ready, I just need feedback on a couple of
>> details:
>>
>> - log->Warning/Debug/Error/Verbose: Currently we have a large number
>> of printf-style logging functions, which are very rarely used (and all
>> they do is prefix the log line with some string), and only one
>> formatv-style. It would be easy to add LLDB_WARN, LLDB_ERR, etc.
>> macros, so that these usages can be ported to the formatv-style.
>> However, I am not sure whether that's really necessary. One of the
>> goals of this process could be to standardize on one function. I would
>> prefer to keep just one log function, but I could be easily convinced
>> otherwise. For reference, these are the current approximate usages of
>> the logging functions (as determined by grep)
>> log->Error: 38 (mostly in ProcessWindows)
>> log->Warning: 25
>> log->Debug: 10 (mostly ClangExpressionParser)
>> log->Verbose: 6 (only ProcessWindows)
>> log->Printf: 2884
>>
> Yea, these are unnecessary and it would be great to get rid of them.
>
>
>>
>> - ProcessWindowsLog: I am not going to go on a reformatting spree to
>> change all logging statements, but I would still like to change remove
>> the logging macros that windows log introduced, since they are very
>> custom, and I'd like to keep the number of logging syntaxes below 3
>> :). Zachary, Adrian, is that OK with you?
>>
> Fine with me, they were only introduced as an alternative to the verbose
> if (log) syntaxes.  If there's an alternative that also solves the problem
> and we can adopt everywhere, then I'm all for it.
>

Fine with me as well.


>
>
>>
>> I must confess have a bit of an ulterior motive for doing this. :) My
>> goal is to start working on the modularization of the codebase. But I
>> don't want it to be just mindless moving of code around. I want to
>> spend some time considering the design of each piece, which should
>> slow things down long enough for the moves to not be annoying, and
>> hopefully produce better components. I'll write more on that soon - I
>> don't want to derail this discussion with it.
>>
> I'd start with one support library which we document and write in stone
> (perhaps even enforce in CMake) that it can have no other dependencies on
> LLDB libraries.  Then start moving various common data structures and
> classes over there.  Like you said, we should save the details for another
> thread, but in any case i look forward to seeing some proposals :)
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] logging in lldb

[Adrian McCarthy via lldb-dev]

> (of those, 7 print the *wrong* function name)

I think this is the best argument for automating the source information as
much as possible.  Refactoring moves stretches of code into new functions.
Log lines get copy and pasted.  Like comments, the fixed text in the log
lines easily gets out of date, which can make reading a log even harder.

If people want the ability to opt-out of source info on certain log lines,
I could live with that.  But I favor default-on and automatically generated
source info.

On Thu, Dec 8, 2016 at 6:46 AM, Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hello again,
>
> I have updated the example code to reflect some of the results from
> this discussion. I think we are generally converging XXX, I am going
> to try to summarize it here, to see if we have any issues left to
> discuss.
>
> - everyone seemed to prefer the formatv-based api, so that should be
> the main API going forward. Printf will need to be maintained until
> all users are migrated. I have updated by example to use that.
>
> - there were concerns about performance characteristics of this in the
> case logging is disabled. I'd like to reiterate that this is one of my
> design goals, and the new proposed API has the same overhead (checking
> for nullness of a local variable) as the current one.
>
> - Related to the previous item, Jim was worried about the usage of a
> macro will hide the fact that macro will hide the fact that the
> performance impact of the logging is small. I replied that anyone
> caring about performance that much will be familiar with this already.
> I also think this is no different than what a lot of other logging
> systems do already  -- llvm's DEBUG(), assert(), boost::log all
> evaluate their arguments only if they are "enabled" (whatever that
> meant exactly), even though the call presents itself as a simple
> macro.
> I am not sure whether this topic is closed. Does anyone want to add
> anything to this?
>
> - there was a discussion about automatically adding log source
> information. My original proposal added it unconditionally. Greg
> suggested we make that optional (similar to how we optionally prepend
> timestamp, thread id, ...). Jim was worried that adding the extra data
> will make hamper readability of the logs. I disagreed.
> Having the source information be optional sounds like a good idea (i'd
> propose to make it on by default, as a log of log lines don't make
> sense without it: "__FUNCTION__ called with signal %d" and similar). I
> am not sure whether this answers Jim's concerns though. Jim, what do
> you say to that? If this would be enough (disabling source information
> on a global level), then great. If not, then we can come up with a way
> to suppress this information on a per-call-site basis. Something like:
> LLGB_LOG_SUPP(log, LogInfo::Source, ...)
> where the second argument would be the list of things to suppress for
> this log line.
>
> BTW, I have done some statistics on a semi-randomly chosen file
> ThreadPlanCallFunction.cpp: This file contains 19 logging statements.
> Of those, 10 print the class name, 8 print the class and function name
> (of those, 7 print the *wrong* function name), and there is only two
> that do not print any source information. One of these prints a table
> of registers, so it could so it could suffer from readability
> problems. However, it does this by printing all registers to a
> temporary stream, and then printing that stream. Since the prepending
> would only add the source before the first line of the log, this could
> be another way to sidestep this problem (just output "\n" before your
> multi-line string). All the other log statements in this file would
> benefit from standardizing on the source printing IMO, as that would
> mean we can actually align things correctly, and visually separate the
> repetitive part (which is already present most of the time), and
> variable part.
> What do you think of that?
>
> - Chris suggested merging lldb and llvm logging infrastructure. I have
> given this some thought, and I think it is possible, although it will
> make the implementation more tricky. I will write a separate email
> about that, but I want to give it more thought (and also, the proposal
> might depend on the exact set of requirements we converge on here).
>
> - anything else I missed?
>
> Cheers,
> pl
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB 4.0.0 crashes on Windows 7

[Adrian McCarthy via lldb-dev]

I'm not able to repro at head (on Windows 7).

On Tue, Dec 6, 2016 at 10:48 AM, Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
> I've also never seen either problem. I'm not debugging Windows apps, but
> Hexagon apps, running lldb and the Hexagon simulator on Win7.
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
> > -Original Message-
> > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eli
> > Zaretskii via lldb-dev
> > Sent: Tuesday, December 06, 2016 10:39 AM
> > To: Zachary Turner 
> > Cc: lldb-dev@lists.llvm.org
> > Subject: Re: [lldb-dev] LLDB 4.0.0 crashes on Windows 7
> >
> > > From: Zachary Turner 
> > > Date: Tue, 06 Dec 2016 16:22:51 +
> > >
> > > I have never seen either of those problems, but I can test it out and
> see if I
> > can reproduce.
> >
> > Thanks.
> >
> > If you are unable to reproduce, I wonder why it happens to me.  The
> system
> > where I installed lldb is just a vanilla Windows 7 box.
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Refactoring in LLDB Windows Plugin

[Adrian McCarthy via lldb-dev]

I have no objection to moving in that direction (enabling remote
debugging).  Zach just pointed out that we'd first have to port lldb-server
to Windows.  Offhand, I don't know how much of an effort that would be.

In the near-term, I'm focused on postmortem debugging, so this wouldn't be
a priority for me for a while.

The "unfactoring" I mentioned in this email is essentially done, though I'm
planning to move some files to eliminate an unnecessary subdirectory from
the source paths.

On Mon, Nov 28, 2016 at 12:43 PM, Greg Clayton  wrote:

> One thing that we have talked about is to move the ProcessWindows stuff
> into lldb-server (it has a NativeProcess and NativeThread class you would
> need to subclass instead of making ProcessWindows and ThreadWindows
> classes) instead of making a native plug-in that is only useful on the
> current system. Then remote windows debugging would be possible. It would
> end up using thee ProcessGDBRemote.cpp process plug-in then. Then the
> ProcessWindows plugin directory would not be needed. Any thoughts on this?
>
> Greg
>
> > On Nov 18, 2016, at 4:00 PM, Adrian McCarthy via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > If you're not working in LLDB's Windows process plugin, you probably
> don't care about this message.
> >
> > FYI:  I'm doing some refactoring (actually unfactoring) in the Windows
> process plugin.  It'll take a series patches over a few days next week.  If
> you're planning on working in this area, please let me know so we can
> coordinate.
> >
> > Details:
> >
> > Last year, I factored the classes like ProcessWindows into pairs of
> classes with names like ProcessWindows and ProcessWindowsLive so that I
> could introduce classes like ProcessWindowsMiniDump that shared common
> code.  Now that the Windows-specific minidump plugin has been superseded by
> the cross-platform minidump plugin, this factoring is no longer necessary.
> Since the factoring creates extra layers that make the code harder to
> understand and maintain, I'd like to undo the split.
> >
> > My plan is to do this in three NFC patches:
> >
> > Patch 1.  Roll the functionality from the common classes into the -Live
> classes.  This will eliminate everything under
> Plugins/Process/Windows/Common and leave the functional code in
> Process/Plugins/Windows/Live.
> >
> > Patch 2.  Rename the -Live classes to shorter, more tractable names.
> >
> > Patch 3.  Move the code up from the Live subdirectory so that it once
> again lives in Plugins/Process/Windows.
> >
> > Patches 2 and 3 could be done in a single step, but I think the history
> will be easier to follow if I keep them separate.
> >
> > If you have any concerns about this plan, please let me know.
> >
> > Adrian.
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Refactoring in LLDB Windows Plugin

[Adrian McCarthy via lldb-dev]

If you're not working in LLDB's Windows process plugin, you probably don't
care about this message.

FYI:  I'm doing some refactoring (actually unfactoring) in the Windows
process plugin.  It'll take a series patches over a few days next week.  If
you're planning on working in this area, please let me know so we can
coordinate.

Details:

Last year, I factored the classes like ProcessWindows into pairs of classes
with names like ProcessWindows and ProcessWindowsLive so that I could
introduce classes like ProcessWindowsMiniDump that shared common code.  Now
that the Windows-specific minidump plugin has been superseded by the
cross-platform minidump plugin, this factoring is no longer necessary.
Since the factoring creates extra layers that make the code harder to
understand and maintain, I'd like to undo the split.

My plan is to do this in three NFC patches:

Patch 1.  Roll the functionality from the common classes into the -Live
classes.  This will eliminate everything under
Plugins/Process/Windows/Common and leave the functional code in
Process/Plugins/Windows/Live.

Patch 2.  Rename the -Live classes to shorter, more tractable names.

Patch 3.  Move the code up from the Live subdirectory so that it once again
lives in Plugins/Process/Windows.

Patches 2 and 3 could be done in a single step, but I think the history
will be easier to follow if I keep them separate.

If you have any concerns about this plan, please let me know.

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

Re: [lldb-dev] LLDB Evolution - Final Form

[Adrian McCarthy via lldb-dev]

My concern about this example:

void do_something(foo *p)
{
assert(p);
if (p)
p->crash();
}

Is that by skipping the operation when the pointer is null is that it's not
clear what it should do if it's precondition isn't met.  Sure, it won't
crash, but it's also not going to "do something."  This can lead to corrupt
state and postpones discovery of the bug.

If do_something is a public API, then, yes, you have to decide, document,
and implement what to do if the caller passes in a null pointer.  If it's
an internal API, then the silent elision of the crash merely hides the bug
possibly corrupts the debugger's state.  A corrupt debugging state seems
(to me) at least as bad as an obvious crash to the user.  Crashes are going
to get complained about and investigated.  Silently doing the wrong thing
just wastes everyone's time.

On Tue, Sep 20, 2016 at 1:59 PM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
>
> On Tue, Sep 20, 2016 at 1:55 PM Greg Clayton  wrote:
>
>>
>> > On Sep 20, 2016, at 1:45 PM, Zachary Turner  wrote:
>> >
>> > I do agree that asserts are sometimes used improperly.  But who's to
>> say that the bug was the assert, and not the surrounding code?  For
>> example, consider this code:
>> >
>> > assert(p);
>> > int x = *p;
>>
>> Should be written as:
>>
>> assert(p);
>> if (!p)
>> do_something_correct();
>> else
>> int x = *p;
>>
>> >
>> > Should this assert also not be here in library code?  I mean it's
>> obvious that the program is about to crash if p is invalid.  Asserts should
>> mean "you're about to invoke undefined behavior", and a crash is *better*
>> than undefined behavior.  It surfaces the problem so that you can't let it
>> slip under the radar, and it also alerts you to the point that the UB is
>> invoked, rather than later.
>> >
>> > What about this assert?
>> >
>> > assert(ptr);
>> > int x = strlen(ptr);
>> >
>> > Surely that assert is ok right?  Do we need to check whether ptr is
>> valid EVERY SINGLE TIME we invoke strlen, or any other function for that
>> matter?  The code would be a disastrous mess.
>>
>> Again, check before you call if this is in a shared library! What is so
>> hard about that? It is called software that doesn't crash.
>>
>> assert(ptr)
>> int x = ptr ? strlen(ptr) : 0;
>>
>
> I find it hard to believe that you are arguing that you cannot EVER know
> ANYTHING about the state of your program.  :-/
>
> This is like arguing that you should run a full heap integrity check every
> time you perform a memory write, just to be sure you aren't about to crash.
>
>
> If you make a std::vector<>, do we need to verify that its internal
> pointer is not null before we write to it?   Probably not, right?  Why
> not?  Because it has a specification of how it works, and it is documented
> that you can construct one, you can use it.
>
> It's ok to document how functions work, and it is ok to assume that
> functions work the way they claim to work.
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Passing std::atomics by value

[Adrian McCarthy via lldb-dev]

Methods like Address::SetOffset and Address::Slide seem to have data races
despite m_offset being atomic.  Callers of those methods would have to
guarantee that nothing else is trying to write to m_offset.  And if they're
doing that, then there doesn't appear to be a need for std::atomic on that
field.

BTW, I propose we move the member variables from protected to private.  As
far as I can tell, there aren't any derived classes (yet), at least none
that access those members.  If we need to add a mutex to the class itself,
it'll be better if any future derived classes access the data through
accessors.

On Fri, Aug 26, 2016 at 11:36 AM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> The thing is, the code is already full of data races.  I think the
> std::atomic is actually used incorrectly and is not even doing anything.
>
> That said, consider darwin on 32-bit, where I believe each stack frame is
> 4-byte aligned.  I dont' think there's any way the compiler can guarantee
> that a function parameter is 8-byte aligned without allocating from the
> heap, which is obviously impossible for a stack variable.
>
> On Fri, Aug 26, 2016 at 11:29 AM Greg Clayton  wrote:
>
>>
>> > On Aug 26, 2016, at 11:24 AM, Greg Clayton via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >
>> >>
>> >> On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >>
>> >> I recently updated to Visual Studio 2015 Update 3, which has improved
>> its diagnostics.  As a result of this, LLDB is uncompilable due to a slew
>> of errors of the following nature:
>> >>
>> >> D:\src\llvm\tools\lldb\include\lldb/Target/Process.h(3256): error
>> C2719: 'default_stop_addr': formal parameter with requested alignment of 8
>> won't be aligned
>> >>
>> >> The issue comes down to the fact that lldb::Address contains a
>> std::atomic, and is being passed by value pervasively throughout
>> the codebase.  There is no way to guarantee that this value is 8 byte
>> aligned.  This has always been a bug, but until now the compiler just
>> hasn't been reporting it.
>> >>
>> >> Someone correct me if I'm wrong, but I believe this is a problem on
>> any 32-bit platform, and MSVC is just the only one erroring.
>> >>
>> >> I'm not really sure what to do about this.  Passing
>> std::atomic's by value seems wrong to me.
>> >>
>> >> Looking at the code, I don't even know why it needs to be atomic.
>> It's not even being used safely.  We'll have a single function write the
>> value and later read the value, even though it could have been used in the
>> meantime. Maybe what is really intended is a mutex.  Or maybe it doesn't
>> need to be atomic in the first place.
>> >>
>> >> Does anyone have a suggestion on what to do about this?  I'm currently
>> blocked on this as I can't compile LLDB.
>> >
>> > Feel free to #ifdef around the m_offset member of Address and you can
>> have the data race and compile. This seems like a compiler bug to me. If a
>> struct/classe by value argument has alignment requirements, then the
>> compiler should handle this correctly IMHO. Am I wrong
>>
>> Or if this isn't a compiler bug, feel free to modify anything that was
>> passing Address by value and make it a "const Address &".
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Evolution

[Adrian McCarthy via lldb-dev]

I assume Christian Convey was referring to clang-format moving the
"//breakpoint here" comments in the tests to different lines.

On Thu, Aug 11, 2016 at 8:15 AM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> It's not possible. The problem is that lldb was dependent on order of
> includes because each header wasn't properly including what it used. So
> when clang-format reordered this, things broke
> On Thu, Aug 11, 2016 at 8:04 AM Christian Convey via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi Pavel,
>>
>> Would it make sense to address this problem by fixing clang-format,
>> rather than working around it?
>>
>> (Assuming the clang-format fix is relatively easy, and acceptable to
>> clang-format's maintainers.)
>>
>> - Christian
>>
>> On Thu, Aug 11, 2016 at 10:41 AM, Pavel Labath via lldb-dev
>>  wrote:
>> > I just committed another  header cleanup commit, which makes lldb
>> > clang-format-immune ( = it still compiles after a full reformat) on
>> > linux. Other OS's are still likely to have some missed dependencies.
>> >
>> > However, when I tried running the test suite I got about 150 failures.
>> > Based on a sample of the errors, it looks like the problem is that
>> > clang format messes up the "// Place breakpoint here" annotations we
>> > use in the tests.
>> > Therefore, I propose to apply the clang-format to the lldb source code
>> > only as a first step. After that, as a second step, we can go through
>> > the tests and fix them up so that the comment markers are where we
>> > expect them to be.
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Introductions

[Adrian McCarthy via lldb-dev]

Cool.  Welcome!

I expect that's very do-able (and it was something on my to-do list,
eventually).

I believe the dump file is relatively trivial.  The Windows API
(::MiniDumpReadDumpStream) just returns ranges of the memory mapped dump
file.  I think you could essentially implement that API in a portable way
and swap it in to the one place in ProcessWinMiniDump that calls it.  Once
that's working, you can hoist it of the Windows-specific world and make it
available everywhere.

On Thu, Jul 21, 2016 at 8:22 AM, Pavel Labath  wrote:

> Hello everyone,
>
> I'd like to introduce Dimitar. He will be with us as an intern for the
> next few months and will be looking into adding minidump support for
> platforms other than windows. Basically, we'd like to add a new
> process plugin which does not depend on native windows api's to parse
> the minidump structures (at which point we can hopefully remove
> ProcessWinMiniDump).
>
> cheers,
> pl
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] compile failure with VS 2015 Update 3

[Adrian McCarthy via lldb-dev]

I left out some words.  I meant:

The answers on that StackOverflow question claim that 32-bit MSVC never
does more than 32-byte alignment *for parameters*.

On Thu, Jun 30, 2016 at 3:12 PM, Adrian McCarthy 
wrote:

> `default_stop_addr` is an `Address` which contains a
> `std::atomic`.  The `addr_t` is a 64-bit value, so I assume
> it needs 64-bit alignment.  The answers on that StackOverflow question
> claim that 32-bit MSVC never does more than 32-byte alignment. So my guess
> is that this has always been a problem, and the newer compiler is just
> better at reporting it.
>
> On Thu, Jun 30, 2016 at 2:56 PM, Philippe Lavoie <
> philippe.lav...@octasic.com> wrote:
>
>> 32-bit.
>> --
>> *From:* Adrian McCarthy [amcca...@google.com]
>> *Sent:* Thursday, June 30, 2016 5:36 PM
>> *To:* Philippe Lavoie
>> *Cc:* lldb-dev@lists.llvm.org
>> *Subject:* Re: [lldb-dev] compile failure with VS 2015 Update 3
>>
>> Compiling for 32-bit or 64-bit?
>>
>> This question looks relevant:
>> http://stackoverflow.com/questions/21743144/using-stdatomic-with-aligned-classes
>>
>> On Thu, Jun 30, 2016 at 1:19 PM, Philippe Lavoie via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hello,
>>>
>>> has anyone tried to compile LLDB with Visual Studio 2015 Update 3 ?
>>>
>>> It compiles fine with Update 2, but with Update 3 we get error messages
>>> like:
>>>
>>> D:\dev\llvm\tools\lldb\include\lldb/Target/Process.h(3194): error
>>> C2719:
>>> 'default_stop_addr': formal parameter with requested alignment of 8
>>> won't be aligned
>>> (compiling source file
>>> D:\dev\llvm\tools\lldb\source\Expression\FunctionCaller.cpp)
>>>
>>> although there is no __declspec(align) on that parameter.
>>> We reported the issue to Microsoft here:
>>>
>>> https://connect.microsoft.com/VisualStudio/feedback/details/2870567/lldb-no-longer-compiles
>>>
>>> -Philippe
>>>
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] compile failure with VS 2015 Update 3

[Adrian McCarthy via lldb-dev]

`default_stop_addr` is an `Address` which contains a
`std::atomic`.  The `addr_t` is a 64-bit value, so I assume
it needs 64-bit alignment.  The answers on that StackOverflow question
claim that 32-bit MSVC never does more than 32-byte alignment. So my guess
is that this has always been a problem, and the newer compiler is just
better at reporting it.

On Thu, Jun 30, 2016 at 2:56 PM, Philippe Lavoie <
philippe.lav...@octasic.com> wrote:

> 32-bit.
> --
> *From:* Adrian McCarthy [amcca...@google.com]
> *Sent:* Thursday, June 30, 2016 5:36 PM
> *To:* Philippe Lavoie
> *Cc:* lldb-dev@lists.llvm.org
> *Subject:* Re: [lldb-dev] compile failure with VS 2015 Update 3
>
> Compiling for 32-bit or 64-bit?
>
> This question looks relevant:
> http://stackoverflow.com/questions/21743144/using-stdatomic-with-aligned-classes
>
> On Thu, Jun 30, 2016 at 1:19 PM, Philippe Lavoie via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hello,
>>
>> has anyone tried to compile LLDB with Visual Studio 2015 Update 3 ?
>>
>> It compiles fine with Update 2, but with Update 3 we get error messages
>> like:
>>
>> D:\dev\llvm\tools\lldb\include\lldb/Target/Process.h(3194): error
>> C2719:
>> 'default_stop_addr': formal parameter with requested alignment of 8
>> won't be aligned
>> (compiling source file
>> D:\dev\llvm\tools\lldb\source\Expression\FunctionCaller.cpp)
>>
>> although there is no __declspec(align) on that parameter.
>> We reported the issue to Microsoft here:
>>
>> https://connect.microsoft.com/VisualStudio/feedback/details/2870567/lldb-no-longer-compiles
>>
>> -Philippe
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] compile failure with VS 2015 Update 3

[Adrian McCarthy via lldb-dev]

Compiling for 32-bit or 64-bit?

This question looks relevant:
http://stackoverflow.com/questions/21743144/using-stdatomic-with-aligned-classes

On Thu, Jun 30, 2016 at 1:19 PM, Philippe Lavoie via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hello,
>
> has anyone tried to compile LLDB with Visual Studio 2015 Update 3 ?
>
> It compiles fine with Update 2, but with Update 3 we get error messages
> like:
>
> D:\dev\llvm\tools\lldb\include\lldb/Target/Process.h(3194): error
> C2719:
> 'default_stop_addr': formal parameter with requested alignment of 8
> won't be aligned
> (compiling source file
> D:\dev\llvm\tools\lldb\source\Expression\FunctionCaller.cpp)
>
> although there is no __declspec(align) on that parameter.
> We reported the issue to Microsoft here:
>
> https://connect.microsoft.com/VisualStudio/feedback/details/2870567/lldb-no-longer-compiles
>
> -Philippe
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Adrian McCarthy via lldb-dev]

>Version numbers aren't strings, and they aren't floating point numbers,
they are a series of integers separated by dots. I can't think of a project
where interpreting version numbers that way won't work.

TeX (asymptotically approaches pi), METAFONT (asymptotically approaches e),
Opera (decimal number).

Sayeth Wikipedia
:

> Most free and open-source software packages, including MediaWiki, treat
> versions as a series of individual numbers, separated by periods, with a
> progression such as 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1,
> 1.11.2, and so on. On the other hand, some software packages identify
> releases by decimal numbers: 1.7, 1.8, 1.81, 1.82, 1.9, etc.


Note that 81 > 8, so those examples would still work.  But 3.10 is easy to
misinterpret as 3.1.

On Thu, Jun 16, 2016 at 2:46 AM, Bruce Hoult via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Bug in cmake (or more likely the makefile?), pure and simple. Version
> numbers aren't strings, and they aren't floating point numbers, they are a
> series of integers separated by dots. I can't think of a project where
> interpreting version numbers that way won't work.
>
> On Wed, Jun 15, 2016 at 7:21 AM, Cristianno Martins via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> Hello there,
>>
>> First, I would like to say that I don't have any strong opinions on this
>> matter: as mostly an user of LLVM, my basic concern is for me to be able to
>> identify which version is the newest and configure it as easily as
>> possible. That being said, I have a question about LLVM's versioning
>> strategy: is it possible for other tools (including the ones LLVM depend
>> on) to become broke or annoyingly buggy just because a bad versioning
>> scheme was put in place?
>>
>> Just to give some context to this question, I've been using OS X for a
>> while, and I confess I was pretty annoyed when OS X 10.9 was followed by OS
>> X 10.10. Not at first, no: I didn't realize this would have any impact on
>> my workspace until I had to compile some code, and CMake kept stopping just
>> because it recognized that I was using an older version of the OS (emphasis
>> on *older*). It is funny when you realize that 10.10 should actually be
>> interpreted as less than 10.9, and CMake was falling for it, which was a
>> wrong behavior of the tool, I admit, but the weird OS versioning scheme was
>> the main cause of this issue. Of course this problem can be easily arranged
>> by setting up some extra environment variables to tell CMake to target OS X
>> 10.9 instead, but that was a very irritating behavior and only happened
>> because a bunch of people (from CMake, and, then, from OS X's development
>> team) thought comparing versions directly shouldn't be a problem. Besides,
>> every one of these small details end up being some extra steps a new user
>> need to follow to be able to use a tool, some of which could be easily
>> avoided.
>>
>> I confess I didn't look into this matter after that, and still today, on
>> OS X 10.11, I'm targeting version 10.9 on all my CMake runs on OS X --
>> thus, I don't know if this bug was fixed or not. However, as I'm starting
>> to see a very similar pattern happening with LLVM on this thread, and I
>> thought I could contribute with the discussion: did someone check if naming
>> the next version "3.10" would have any impact on a production system?
>>
>>
>> --
>> Cristianno Martins
>> 
>>
>> On Tue, Jun 14, 2016 at 10:48 PM, Sean Silva via llvm-dev <
>> llvm-...@lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev <
>>> cfe-...@lists.llvm.org> wrote:
>>>


 On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev <
 cfe-...@lists.llvm.org> wrote:

> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> - Original Message -
>> > From: "Hans Wennborg via cfe-dev" 
>> > To: "llvm-dev" , "cfe-dev" <
>> cfe-...@lists.llvm.org>, "LLDB Dev" ,
>> > "openmp-dev (openmp-...@lists.llvm.org)" > >
>> > Cc: "r jordans" , "Paul Robinson" <
>> paul_robin...@playstation.sony.com>
>> > Sent: Monday, June 13, 2016 6:54:19 PM
>> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9
>> Release] Release plan and call for testers)
>> >
>> > Breaking this out into a separate thread since it's kind of a
>> > separate
>> > issue, and to make sure people see it.
>> >
>> > If you have opinions on this, please chime in. I'd like to collect
>> as
>> > many arguments here as possible to make a good decision. The main
>> > contestants are 4.0 and 3.10, and I've seen folks being equally
>> > surprised by both.
>> >
>> > Brain-dump so far:
>> >
>> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0
>> > comes after 3.9.
>> >
>> > 

Re: [lldb-dev] Listing memory regions in lldb

[Adrian McCarthy via lldb-dev]

>
> Interestingly when I've worked on Windows core dumps before I've seen that
> MiniDump, with the right flags, will deliberately insert a region in the
> middle of the memory ranges to represent the unmapped space, on 64 bit it's
> quite a large section.


Are you saying that's a bug in the minidump itself or in LLDB's handling of
it?  If the latter, please send me the details (e.g., which flags trigger
this behavior), and I'll see what I can do about it.

Adrian.

On Fri, May 13, 2016 at 3:35 AM, Howard Hellyer via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I have experimented with the GetMemoryRegionInfo approach on the internal
> APIs already, it has some positives and negatives.
>
> - GetMemoryRegionInfo is unimplemented for Linux and Mac core dumps.
> That's not necessarily a bad thing as it could be implemented the "right"
> way. (As Jim said GetMemoryRegionInfo would have to return the right thing
> for an unmapped region.) Interestingly when I've worked on Windows core
> dumps before I've seen that MiniDump, with the right flags, will
> deliberately insert a region in the middle of the memory ranges to
> represent the unmapped space, on 64 bit it's quite a large section.
>
> - Using GetMemoryRegionInfo to iterate might be quite expensive if there
> are many small memory regions.
>
> - One reason I hadn't looked at just exposing an SBGetMemoryRegionInfo is
> that it wouldn't match a lot of the SB API's at the moment (for example for
> Threads and Sections) which tend work by having GetNumXs() and
> GetXAtIndex() calls. Iterating with SBGetMemoryRegionInfo would be
> non-obvious to the user of the API since it doesn't match the convention.
> It would need to be documented in the SBGetMemoryRegionInfo API.
>
> - I've found the only way to reliably filter out inaccessible memory is to
> do a test read and check the error return code. I'm pretty sure I've seen
> some that are readable via a memory read but marked read=false,
> write=false, execute=false. (I can't remember the exact case now off the
> top of my head, but I think it might have been allocated but uncommitted
> memory or similar.)
>
> - Using GetMemoryRegionInfo over a remote connection on Linux and Mac
> worked well but seemed to coalesce some of the memory regions together. It
> also only allows for read/write/exec attributes to be passed. That's a
> shame as a live process can often tell you more about what the region is
> for. The remote command memory map looks like it sends back XML so it might
> be possible to insert custom properties in there to give more information
> but I'm not sure how safe it is to do that, I don't know the project quite
> well enough to understand all the use cases for the protocol.
>
> - Extended infomation /proc/pid/maps marking a region as [stack] would be
> lost. All you would get is read/write/exec info. (That said supporting
> everything every platform can provide might be a bit much.)
>
> - LLDB's ReadMemory implementations seem to return 0's for missing memory
> that should be accessible. It might be nice to include whether the memory
> is backed by real data or not in the API. (For example Linux core files can
> be missing huge pages depending on the setting of /proc/PID/coredump_filter
> or files can simply be truncated.)
>
> I could implement the GetMemoryRegionInfo iteration mechanism pretty
> quickly and it would actually fit my purposes as far as providing all the
> addresses you can sensibly access.
>
> I'm quite keen to provide a patch but don't want to provide one that is at
> odds with how the rest of lldb works or provides data that's only useful to
> me so I'm quite keen to get a bit of feedback on what the preferred
> approach would be. It could be that providing both SBGetMemoryRegionInfo
> and the SBGetNumMemoryRegions/SBGetMemoryRegionAtIndex pair is the right
> solution.
>
> Would a patch also need to provide a command to dump this information as
> it can be awkward to have data that's only accessible via the API?
>
> *Howard Hellyer*
> IBM Runtime Technologies, IBM Systems
>
>
>
>
> Greg Clayton  wrote on 12/05/2016 19:09:49:
>
> > From: Greg Clayton 
> > To: Howard Hellyer/UK/IBM@IBMGB
> > Cc: lldb-dev@lists.llvm.org
> > Date: 12/05/2016 19:10
> > Subject: Re: [lldb-dev] Listing memory regions in lldb
> >
> > We have a way internally with:
> >
> > virtual Error
> > lldb_private::Process::GetMemoryRegionInfo (lldb::addr_t
> > load_addr, MemoryRegionInfo &range_info);
> >
> > This isn't expose via the public API in lldb::SBProcess. If you
> > want, you can expose this. We would need to expose a
> > SBMemoryRegionInfo and the call could be:
> >
> > namespace lldb
> > {
> > class SBProcess
> > {
> > SBError GetMemoryRegionInfo (lldb::addr_t load_addr,
> > SBMemoryRegionInfo &range_info);
> > };
> > }
> >
> > then you would call this API with address zero and it would return a
> > SBMemoryRegionInfo with an address range and if that memory is read/
> > wri

Re: [lldb-dev] What's the purpose of the TestStarted-XXX and TestFinished-XXX files?

[Adrian McCarthy via lldb-dev]

Thanks.  I have a patch out that removes the files that I'll probably
submit today.

On Thu, Mar 10, 2016 at 1:44 AM, Pavel Labath  wrote:

> I don't think anyone is relying on these. We should just stop creating
> them altogether.
>
> We are using the *.log files to track test results over time, but we
> don't need these files there. You can detect crashing tests by the
> fact that the log files don't have a "TestResult-" (Success, Failure,
> Error, ...) prefix. We have a script for doing that here
> <
> https://android.googlesource.com/platform/external/lldb-utils/+/lldb-master-dev/buildbotScripts/logParser/doParse.py
> >,
> but it's very specific to our buildbot setup, so it may not be very
> useful to you...
>
>
>
> On 9 March 2016 at 23:04, Greg Clayton via lldb-dev
>  wrote:
> > I would be happy to see these files go away if no one is using them...
> >
> >> On Mar 9, 2016, at 2:32 PM, Adrian McCarthy via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> The test traces directory tends to accumulate thousands and thousands
> of TestStarted-XXX and TestFinished-XXX files.  What purpose do they serve?
> >>
> >> I assume it's for trying to figure out why something went wrong.  If
> you have a TestStarted-123 without a corresponding TestFinished-123, then
> you can know that a test crashes and by looking inside the file, you can
> see which test and what the command was.
> >>
> >> If that's the case, then wouldn't it be cleaner to delete the
> TestStarted file when the test finishes rather than writing a second file?
> Then you can simply search for TestStarted files to see the ones that
> didn't finish successfully without the noise of thousands of others that
> did.
> >>
> >> I suppose it's also possible that some other process is looking at
> these files in order to collect statistics.  Is there such a beast and is
> it valuable?
> >>
> >> Adrian.
> >> ___
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] What's the purpose of the TestStarted-XXX and TestFinished-XXX files?

[Adrian McCarthy via lldb-dev]

The test traces directory tends to accumulate thousands and thousands of
TestStarted-XXX and TestFinished-XXX files.  What purpose do they serve?

I assume it's for trying to figure out why something went wrong.  If you
have a TestStarted-123 without a corresponding TestFinished-123, then you
can know that a test crashes and by looking inside the file, you can see
which test and what the command was.

If that's the case, then wouldn't it be cleaner to delete the TestStarted
file when the test finishes rather than writing a second file?  Then you
can simply search for TestStarted files to see the ones that didn't finish
successfully without the noise of thousands of others that did.

I suppose it's also possible that some other process is looking at these
files in order to collect statistics.  Is there such a beast and is it
valuable?

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

Re: [lldb-dev] FYI: a python crash running tests

[Adrian McCarthy via lldb-dev]

Did you ever push a fix?  I'm still seeing this problem, even after a fresh
sync.

I'm happy to take a look at it today if you don't already have a fix.

On Thu, Mar 3, 2016 at 10:18 AM, Ted Woodward 
wrote:

> I think I see the problem; I’ll push up a fix.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* Zachary Turner [mailto:ztur...@google.com]
> *Sent:* Thursday, March 03, 2016 11:54 AM
> *To:* Adrian McCarthy; LLDB; Ted Woodward
> *Subject:* Re: FYI: a python crash running tests
>
>
>
> Hi Ted, any chance this is your recent change? I know you had some changes
> in this file recently
>
> On Wed, Mar 2, 2016 at 4:46 PM Adrian McCarthy 
> wrote:
>
> Running ninja check-lldb now has one crash in a Python process, due to
> deferencing a null pointer in IRExecutionUnit.cpp:  candidate_sc.symbol is
> null, which leads to a call with a null this pointer.
>
>
>
> However, the Test Result Summary shows no problems:  0 failures, errors,
> exceptional exits, and timeouts.
>
>
>
> I would try to debug it, but I'm about to head out.
>
>
>
> Adrian.
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Minidump support in LLDB

[Adrian McCarthy via lldb-dev]

Below is an after-the-fact design doc on the minidump support in LLDB.  We
don't seem to have a documents repository, so I thought I'd post it here on
the mailing list in case anyone wants to know more.  Comments and questions
welcome.

Thanks,
Adrian.

---
Minidump support in LLDB

Adrian McCarthy

amcca...@google.com

This is an “as-built” design document describing how minidump support was
added to LLDB on Windows.

Minidumps are the Windows equivalent of a core file.  The format is
well-documented (unlike core files), so some crash-reporting tools (like
Breakpad) have chosen to use the minidump format not only on Windows, but
also on all other platforms

it supports.  Chromium and other Google projects use Breakpad, so minidump
support in LLDB is important for Google.
Status

Currently, LLDB supports debugging 32-bit minidumps on Windows for binaries
built with DWARF debug information (e.g., with clang-cl).  Tests ensure
that we can see stacks for all threads and inspect local variables and
parameters and that it is possible to inspect any section of process memory
captured in the dump.
Process Plugin for Minidump

A new process plugin was created for minidump support.  It parallels the
Windows process plugin (for debugging live processes on Windows) and the
ELF core process plugin (for postmortem analysis of core files).

The minidump plugin is smaller than the ELF core plugin, largely because
the ELF core plugin contains all of the code for parsing a core file.  The
minidump plugin currently relies on a Windows API and structure definitions
in order to parse it.  The minidump format appears simpler than the core
file format.  Nevertheless, if we decide to parse it directly in LLDB, the
parsing code should probably be in a separate translation unit than the
minidump plugin.

The minidump plugin is also smaller than the Windows process plugin, which
handles debugging of live processes.  Debugging a live process on Windows
involves tracking more state and managing a separate debugger thread for
receiving and dispatching debugging events.

Small parts of the existing ProcessWindows plugin were factored up into a
new base class to be used by both the ProcessWindowsLive and the new
ProcessWindowsMiniDump process plugins.

Small amounts of code were factored out of the Windows-specific Register
and Thread classes so they could also be re-used by the minidump
counterparts.  The minidump versions of these classes are simpler than
their live-debugging counterparts since they are read-only.

Upon opening the minidump, the plugin reads several sections in order to
capture the process ID, the module list, and the exception record.  The
plugin extracts information about the threads that were running when LLDB
calls back into the plugin’s UpdateThreadList.

As a first pass, LLDB supports Minidump only on Windows, because it uses
the Windows-provided API MiniDumpReadDumpStream for accessing the
minidump.  But use of this API is localized to a single location, so it can
easily be swapped out for an independent implementation of this
functionality.
Writing Minidumps

The `process save-core` command was extended for Windows to create a
minidump file.  It currently uses the Windows API MiniDumpWriteDump
.
As with reading, this could be replaced to allow writing a minidump on any
platform.  That would require an option on the `process save-core` command
in order to specify which format was desired when there is a choice (we’re
not like to start offer Unix-style core files on Windows).

Since the minidump format is documented and not particularly complex,
providing another implementation should be straightforward and would allow
for debugging minidumps on MacOS or Linux, even if those minidumps are from
a Windows host.
Testing

There are a small number of basic tests to ensure that LLDB can open a
minidump, find the threads, inspect the stack and local variables, and
write a minidump.

Some of these tests execute against checked-in minidumps that were captured
with Visual Studio and others use LLDB’s ability to write a minidump to
first capture a dump and then to inspect it.  We need tests that check
minidumps from more elaborate (or, at least larger scale) programs.
Future Work

   -

   Test minidump debugging functionality with a substantial application
   like Chromium.
   -

   Read the minidump directly instead of using the Windows API interface.
   This would be the key step in making cross-platform crash dump analysis
   possible.
   -

   Implement the 64-bit register model for Windows crash-dump debugging.
   There is a bit of work here to make sure it works on WoW32.
   -

   Write minidumps on any platform by implementing our own version of
   MiniDumpWriteDump and adding an option to the `process save-core` command
   to select the format.
   - Investiga

Re: [lldb-dev] Problem with dotest_channels.py

[Adrian McCarthy via lldb-dev]

With Todd's change, I was getting a Ninja crash.  Zach and I replaced the
returns Todd added with raises, in order to propagate the exception up the
stack, and that avoids the Ninja crash, so I'll check that in in a moment.

In the mean time, here's the error message we got out of it.

155 out of 416 test suites processed - TestBacktraceAll.py
INFO: received socket error when reading data from test inferior:
[Errno 10054] An existing connection was forcibly closed by the remote host
error: uncaptured python exception, closing channel
 (:[Errno 10054] An existing
connection was forcibly closed by the remote host
[D:\Python_for_lldb\x86\lib\asyncore.py|read|83]
[D:\Python_for_lldb\x86\lib\asyncore.py|handle_read_event|449]
[D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest_channels.py|handle_read|137]
[D:\Python_for_lldb\x86\lib\asyncore.py|recv|387])
175 out of 416 test suites processed - TestNoSuchArch.py

On Mon, Dec 14, 2015 at 3:58 PM, Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hey Zachary,
>
> I just put in:
> r255581
>
> which should hopefully:
> (1) catch the exception you see there,
> (2) handle it gracefully in the common and to-be-expected case of the test
> inferior going down hard, and
> (3) print out an error if anything else unexpected is happening here.
>
> Let me know if you get any more info with it.  Thanks!
>
> -Todd
>
> On Mon, Dec 14, 2015 at 2:16 PM, Todd Fiala  wrote:
>
>> Yeah that's a messed up exception scenario that is hard to read.  I'll
>> figure something out when I repro it.  One side is closing before the other
>> is expecting it, but likely in a way we need to expect.
>>
>> I think it is ugly-ified because it is coming from some kind of worker
>> thread within async-core.
>>
>> I will get something in to help it today.  The first bit may be just
>> catching the exception as you mentioned.
>>
>> On Mon, Dec 14, 2015 at 2:05 PM, Zachary Turner 
>> wrote:
>>
>>> If nothing else, maybe we can print out a more useful exception
>>> backtrace.  What kind of exception, what line, and what was the message?
>>> That might help give us a better idea of what's causing it.
>>>
>>> On Mon, Dec 14, 2015 at 2:03 PM Todd Fiala  wrote:
>>>
 Hi Zachary!





 On Mon, Dec 14, 2015 at 1:28 PM, Zachary Turner via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

> Hi Todd, lately I've been seeing this sporadically when running the
> test suite.
>
> [TestNamespaceLookup.py FAILED]
> Command invoked: C:\Python27_LLDB\x86\python_d.exe
> D:\src\llvm\tools\lldb\test\dotest.pyc -q --arch=i686 --executable
> D:/src/llvmbuild/ninja/bin/lldb.exe -s
> D:/src/llvmbuild/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS
> --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe
> --results-port 55886 --inferior -p TestNamespaceLookup.py
> D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test --event-add-entries
> worker_index=10:int
> 416 out of 416 test suites processed - TestAddDsymCommand.py
> error: uncaptured python exception, closing channel
>  connected
> 127.0.0.1:56008 at 0x2bdd578> (:[Errno 10054]
> An existing connection was forcibly closed by the remote host
> [C:\Python27_LLDB\x86\lib\asyncore.py|read|83]
> [C:\Python27_LLDB\x86\lib\asyncore.py|handle_read_event|449]
> [D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest_channels.py|handle_read|133]
> [C:\Python27_LLDB\x86\lib\asyncore.py|recv|387])
>
> It seems to happen randomly and not always on the same test.
> Sometimes it doesn't happen at all.  I wonder if this could be related to
> some of the work that's been going on recently.  Are you seeing this?  Any
> idea how to diagnose?
>

 Eww.

 That *looks* like one side of the connection between the inferior and
 the test runner process choked on reading content from the test event
 socket when the other end went down.  Reading it a bit more carefully, it
 looks like it is the event collector (which would be the parallel test
 runner side) that was receiving when the socket went down.

 I think this means I just need to put a try block around the receiver
 and just bail out gracefully (possibly with a message) when that happens at
 an unexpected time.  Since test inferiors can die at any time, possibly due
 to a timeout where they are forcibly killed, we do need to handle that
 gracefully.'

 I'll see if I can force it, replicate it, and fix it.  I'll look at
 that now (pending watching the buildbots for the other change I just put
 in).

 And yes, this would be a code path that we use heavily with the xUnit
 reporter, but only started getting used by you more recently when I turned
 on the newer summary results by default.  (The newer summary results use
 the test event system, which means test inferior

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

[Adrian McCarthy via lldb-dev]

eback*, 
>>>>> even
>>>>> though we're completely out of the finally block.  What this means is that
>>>>> if you call `sys.exc_info()` *even after you've exited the finally block,
>>>>> it still returns info about the previous exception that's not even being
>>>>> handled anymore.  I would have expected this to be gone since there's no
>>>>> exception in-fligth anymore.  So basically, Python is still holding a
>>>>> reference to the active exception, the exception holds the stack frame, 
>>>>> the
>>>>> stack frame holds the test method, the test method has locals, one of 
>>>>> which
>>>>> is a SymbolList, a member of which is symbol context, which has the file
>>>>> locked.
>>>>>
>>>>> Our best guess is that if you have something like this:
>>>>>
>>>>> def foo():
>>>>> try:
>>>>># Do stuff
>>>>> except Exception, e:
>>>>>pass
>>>>> # Do more stuff
>>>>>
>>>>> that if the exceptional path is executed, then both e and
>>>>> sys.exc_info() are alive *while* do more stuff is happening.  We've found
>>>>> two ways to fixthis:
>>>>>
>>>>> 1) Change to this:
>>>>> def foo():
>>>>> try:
>>>>># Do stuff
>>>>> except Exception, e:
>>>>>pass
>>>>> del e
>>>>> sys.exc_clear()
>>>>> # Do more stuff
>>>>>
>>>>> 2) Put the try / except inside a function.  When the function returns,
>>>>> sys.exc_info() is cleared.
>>>>>
>>>>> I like 2 better, but we're still testing some more to make sure this
>>>>> really fixes it 100% of the time.
>>>>>
>>>>> On Thu, Oct 15, 2015 at 10:25 AM Greg Clayton via lldb-dev <
>>>>> lldb-dev@lists.llvm.org> wrote:
>>>>>
>>>>>>
>>>>>> > On Oct 15, 2015, at 8:50 AM, Adrian McCarthy via lldb-dev <
>>>>>> lldb-dev@lists.llvm.org> wrote:
>>>>>> >
>>>>>> > I've tracked down a source of flakiness in tests on Windows to
>>>>>> Python object lifetimes and the SB interface, and I'm wondering how best 
>>>>>> to
>>>>>> handle it.
>>>>>> >
>>>>>> > Consider this portion of a test from TestTargetAPI:
>>>>>> >
>>>>>> >  def find_functions(self, exe_name):
>>>>>> >  """Exercise SBTaget.FindFunctions() API."""
>>>>>> >  exe = os.path.join(os.getcwd(), exe_name)
>>>>>> >
>>>>>> >  # Create a target by the debugger.
>>>>>> >  target = self.dbg.CreateTarget(exe)
>>>>>> >  self.assertTrue(target, VALID_TARGET)
>>>>>> >  list = target.FindFunctions('c', lldb.eFunctionNameTypeAuto)
>>>>>> >  self.assertTrue(list.GetSize() == 1)
>>>>>> >
>>>>>> >  for sc in list:
>>>>>> >  self.assertTrue(sc.GetModule().GetFileSpec().GetFilename()
>>>>>> == exe_name)
>>>>>> >  self.assertTrue(sc.GetSymbol().GetName() == 'c')
>>>>>> >
>>>>>> > The local variables go out of scope when the function exits, but
>>>>>> the SB (C++) objects they represent aren't (always) immediately 
>>>>>> destroyed.
>>>>>> At least some of these objects keep references to the executable module 
>>>>>> in
>>>>>> the shared module list, so when the test framework cleans up and calls
>>>>>> `SBDebugger::DeleteTarget`, the module isn't orphaned, so LLDB maintains 
>>>>>> an
>>>>>> open handle to the executable.
>>>>>>
>>>>>> Creating a target with:
>>>>>>
>>>>>> target = self.dbg.CreateTarget(exe)
>>>>>>
>>>>>> Will give you a SBTarget object that has a strong reference to the
>>>>>> target, but the debugger still has a copy in its target list, so

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

[Adrian McCarthy via lldb-dev]

The gc.collect works only if I set the variables to None in the finally
blocks, which is no better than just del'ing the objects in the finally
blocks.

On Thu, Oct 15, 2015 at 9:47 AM, Adrian McCarthy 
wrote:

>
> On Thu, Oct 15, 2015 at 9:31 AM, Todd Fiala  wrote:
>
>>
>>
>> On Thu, Oct 15, 2015 at 9:23 AM, Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> That wouldn't work in this case because it causes a failure from one
>>> test to the next.  So a single test suite has 5 tests, and the second one
>>> fails because the first one didn't clean up correctly.  You couldn't call
>>> ScriptInterpreterpython::Clear here, because then you'd have to initialize
>>> it again, and while it might work, it seems scary and like something which
>>> is untested and we recommend you don't do.
>>>
>>> What about calling `gc.collect()` in the tearDown() method?
>>>
>>
>> If it's a laziness thing, that seems like it might do it.  I would think
>> we could stick that in the base test class and get it everywhere.  Is that
>> something you can try, Adrian?
>>
>
> That seemed promising, but it doesn't seem to work, so maybe I don't
> understand the problem as well as I thought I did.
>
>
>>
>>
>>>
>>> On Thu, Oct 15, 2015 at 9:10 AM Oleksiy Vyalov via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>>> I stumbled upon similar problem when was looking into why SBDebugger
>>>> wasn't unloaded upon app's exit.
>>>> The problem was in Python global objects like lldb.debugger,
>>>> lldb.target sitting around.
>>>> So, my guess is to try to call ScriptInterpreterPython::Clear  within
>>>> test's tearDown call - e.g., expose Clear method as part of
>>>> SBCommandInterpreter and call it via SBDebugger::GetCommandInterpreter
>>>>
>>>> On Thu, Oct 15, 2015 at 8:50 AM, Adrian McCarthy via lldb-dev <
>>>> lldb-dev@lists.llvm.org> wrote:
>>>>
>>>>> I've tracked down a source of flakiness in tests on Windows to Python
>>>>> object lifetimes and the SB interface, and I'm wondering how best to 
>>>>> handle
>>>>> it.
>>>>>
>>>>> Consider this portion of a test from TestTargetAPI:
>>>>>
>>>>> def find_functions(self, exe_name):
>>>>> """Exercise SBTaget.FindFunctions() API."""
>>>>> exe = os.path.join(os.getcwd(), exe_name)
>>>>>
>>>>> # Create a target by the debugger.
>>>>> target = self.dbg.CreateTarget(exe)
>>>>> self.assertTrue(target, VALID_TARGET)
>>>>> list = target.FindFunctions('c', lldb.eFunctionNameTypeAuto)
>>>>> self.assertTrue(list.GetSize() == 1)
>>>>>
>>>>> for sc in list:
>>>>> self.assertTrue(sc.GetModule().GetFileSpec().GetFilename()
>>>>> == exe_name)
>>>>> self.assertTrue(sc.GetSymbol().GetName() == 'c')
>>>>>
>>>>> The local variables go out of scope when the function exits, but the
>>>>> SB (C++) objects they represent aren't (always) immediately destroyed.  At
>>>>> least some of these objects keep references to the executable module in 
>>>>> the
>>>>> shared module list, so when the test framework cleans up and calls
>>>>> `SBDebugger::DeleteTarget`, the module isn't orphaned, so LLDB maintains 
>>>>> an
>>>>> open handle to the executable.
>>>>>
>>>>> The result of the lingering handle is that, when the next test case in
>>>>> the test suite tries to re-build the executable, it fails because the file
>>>>> is not writable.  (This is problematic on Windows because the file system
>>>>> works differently in this regard than Unix derivatives.)  Every subsequent
>>>>> case in the test suite fails.
>>>>>
>>>>> I managed to make the test work reliably by rewriting it like this:
>>>>>
>>>>> def find_functions(self, exe_name):
>>>>> """Exercise SBTaget.FindFunctions() API."""
>>>>> exe = os.path.join(os.getcwd(), exe_name)
>>>>>
>>>

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

[Adrian McCarthy via lldb-dev]

On Thu, Oct 15, 2015 at 9:31 AM, Todd Fiala  wrote:

>
>
> On Thu, Oct 15, 2015 at 9:23 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> That wouldn't work in this case because it causes a failure from one test
>> to the next.  So a single test suite has 5 tests, and the second one fails
>> because the first one didn't clean up correctly.  You couldn't call
>> ScriptInterpreterpython::Clear here, because then you'd have to initialize
>> it again, and while it might work, it seems scary and like something which
>> is untested and we recommend you don't do.
>>
>> What about calling `gc.collect()` in the tearDown() method?
>>
>
> If it's a laziness thing, that seems like it might do it.  I would think
> we could stick that in the base test class and get it everywhere.  Is that
> something you can try, Adrian?
>

That seemed promising, but it doesn't seem to work, so maybe I don't
understand the problem as well as I thought I did.


>
>
>>
>> On Thu, Oct 15, 2015 at 9:10 AM Oleksiy Vyalov via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> I stumbled upon similar problem when was looking into why SBDebugger
>>> wasn't unloaded upon app's exit.
>>> The problem was in Python global objects like lldb.debugger, lldb.target
>>> sitting around.
>>> So, my guess is to try to call ScriptInterpreterPython::Clear  within
>>> test's tearDown call - e.g., expose Clear method as part of
>>> SBCommandInterpreter and call it via SBDebugger::GetCommandInterpreter
>>>
>>> On Thu, Oct 15, 2015 at 8:50 AM, Adrian McCarthy via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>>> I've tracked down a source of flakiness in tests on Windows to Python
>>>> object lifetimes and the SB interface, and I'm wondering how best to handle
>>>> it.
>>>>
>>>> Consider this portion of a test from TestTargetAPI:
>>>>
>>>> def find_functions(self, exe_name):
>>>> """Exercise SBTaget.FindFunctions() API."""
>>>> exe = os.path.join(os.getcwd(), exe_name)
>>>>
>>>> # Create a target by the debugger.
>>>> target = self.dbg.CreateTarget(exe)
>>>> self.assertTrue(target, VALID_TARGET)
>>>> list = target.FindFunctions('c', lldb.eFunctionNameTypeAuto)
>>>> self.assertTrue(list.GetSize() == 1)
>>>>
>>>> for sc in list:
>>>> self.assertTrue(sc.GetModule().GetFileSpec().GetFilename()
>>>> == exe_name)
>>>> self.assertTrue(sc.GetSymbol().GetName() == 'c')
>>>>
>>>> The local variables go out of scope when the function exits, but the SB
>>>> (C++) objects they represent aren't (always) immediately destroyed.  At
>>>> least some of these objects keep references to the executable module in the
>>>> shared module list, so when the test framework cleans up and calls
>>>> `SBDebugger::DeleteTarget`, the module isn't orphaned, so LLDB maintains an
>>>> open handle to the executable.
>>>>
>>>> The result of the lingering handle is that, when the next test case in
>>>> the test suite tries to re-build the executable, it fails because the file
>>>> is not writable.  (This is problematic on Windows because the file system
>>>> works differently in this regard than Unix derivatives.)  Every subsequent
>>>> case in the test suite fails.
>>>>
>>>> I managed to make the test work reliably by rewriting it like this:
>>>>
>>>> def find_functions(self, exe_name):
>>>> """Exercise SBTaget.FindFunctions() API."""
>>>> exe = os.path.join(os.getcwd(), exe_name)
>>>>
>>>> # Create a target by the debugger.
>>>> target = self.dbg.CreateTarget(exe)
>>>> self.assertTrue(target, VALID_TARGET)
>>>>
>>>> try:
>>>> list = target.FindFunctions('c', lldb.eFunctionNameTypeAuto)
>>>> self.assertTrue(list.GetSize() == 1)
>>>>
>>>> for sc in list:
>>>> try:
>>>>
>>>> self.assertTrue(sc.GetModule().GetFileSpec().GetFilename() == exe_name)
>>>

[lldb-dev] Python object lifetimes affect the reliability of tests

[Adrian McCarthy via lldb-dev]

I've tracked down a source of flakiness in tests on Windows to Python
object lifetimes and the SB interface, and I'm wondering how best to handle
it.

Consider this portion of a test from TestTargetAPI:

def find_functions(self, exe_name):
"""Exercise SBTaget.FindFunctions() API."""
exe = os.path.join(os.getcwd(), exe_name)

# Create a target by the debugger.
target = self.dbg.CreateTarget(exe)
self.assertTrue(target, VALID_TARGET)
list = target.FindFunctions('c', lldb.eFunctionNameTypeAuto)
self.assertTrue(list.GetSize() == 1)

for sc in list:
self.assertTrue(sc.GetModule().GetFileSpec().GetFilename() ==
exe_name)
self.assertTrue(sc.GetSymbol().GetName() == 'c')

The local variables go out of scope when the function exits, but the SB
(C++) objects they represent aren't (always) immediately destroyed.  At
least some of these objects keep references to the executable module in the
shared module list, so when the test framework cleans up and calls
`SBDebugger::DeleteTarget`, the module isn't orphaned, so LLDB maintains an
open handle to the executable.

The result of the lingering handle is that, when the next test case in the
test suite tries to re-build the executable, it fails because the file is
not writable.  (This is problematic on Windows because the file system
works differently in this regard than Unix derivatives.)  Every subsequent
case in the test suite fails.

I managed to make the test work reliably by rewriting it like this:

def find_functions(self, exe_name):
"""Exercise SBTaget.FindFunctions() API."""
exe = os.path.join(os.getcwd(), exe_name)

# Create a target by the debugger.
target = self.dbg.CreateTarget(exe)
self.assertTrue(target, VALID_TARGET)

try:
list = target.FindFunctions('c', lldb.eFunctionNameTypeAuto)
self.assertTrue(list.GetSize() == 1)

for sc in list:
try:

self.assertTrue(sc.GetModule().GetFileSpec().GetFilename() == exe_name)
self.assertTrue(sc.GetSymbol().GetName() == 'c')
finally:
del sc

finally:
del list

The finally blocks ensure that the corresponding C++ objects are destroyed,
even if the function exits as a result of a Python exception (e.g., if one
of the assertion expressions is false and the code throws an exception).
Since the objects are destroyed, the reference counts are back to where
they should be, and the orphaned module is closed when the target is
deleted.

But this is ugly and maintaining it would be error prone.  Is there a
better way to address this?

In general, it seems bad that our tests aren't well-isolated.  I sympathize
with the concern that re-starting LLDB for each test case would slow down
testing, but I'm also concerned that the state of LLDB for any given test
case can depend on what happened in the earlier cases.

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

Re: [lldb-dev] Too many open files

[Adrian McCarthy via lldb-dev]

Zach had the clue that found the problem.  Python on Windows uses the stdio
from CRT.  On Windows, the default limit for open file descriptors is 512.
When you have 40 logical cores and the parent process spends several FDs
communicating with each one, you get real close to that number.

https://msdn.microsoft.com/en-us/library/6e3b887c.aspx

As a test, I hacked a _setmaxstdio(2048) into the main() of my local copy
of Python, and the problem went away.

I guess the general solution is to limit the number of processes on
Windows, which we already knew was a possible workaround.


On Wed, Oct 7, 2015 at 3:17 PM, Adrian McCarthy  wrote:

> Adding a printing destructor to threading.Event seems to aggravate timing
> problems, causing several tests to fail to make their inferiors and that
> seemingly keeps us below the open file limit.  That aside, the destructor
> did fire many hundreds of times, so there's not a general problem stopping
> all or even most of those to be cleaned up.
>
> The event objects that I'm seeing with the Sysinternals tools are likely
> Windows Events that Python creates to facilitate the interprocess
> communication.
>
> I'm looking at the ProcessDriver lifetimes now.
>
> On Tue, Oct 6, 2015 at 9:54 AM, Todd Fiala  wrote:
>
>> Okay.
>>
>> A promising avenue might be to look at how Windows cleans up the
>> threading.Event objects.  Chasing that thread might yield why the events
>> are not going away (assuming those are the events that are lingering on
>> your end).  One thing you could consider doing is patching in a replacement
>> destructor for the threading.Event and print something when it fires off,
>> verifying that they're really going away from the Python side.  If they're
>> not, perhaps there's a retain bloat issue where we're not getting rid of
>> some python objects due to some unintended references living beyond
>> expectations.
>>
>> The dosep.py call_with_timeout method drives the child process operation
>> chain.  That thing creates a ProcessDriver and collects the results from it
>> when done.  Everything within the ProcessDriver (including the event)
>> should be cleaned up by the time the call_with_timeout() call wraps up as
>> there shouldn't be any references outstanding.  It might also be worth you
>> adding a destructor to the ProcessDriver to make sure that's going away,
>> one per Python test inferior executed.
>>
>> On Tue, Oct 6, 2015 at 9:48 AM, Adrian McCarthy 
>> wrote:
>>
>>> Python 2.7.10 made no difference.  I'm dealing with other issues this
>>> afternoon, so I'll probably return to this on Wednesday.  It's not critical
>>> since there are workarounds.
>>>
>>> On Tue, Oct 6, 2015 at 9:41 AM, Todd Fiala  wrote:
>>>


 On Mon, Oct 5, 2015 at 3:58 PM, Adrian McCarthy 
 wrote:

> Different tools are giving me different numbers.
>
> At the time of the error, Windbg says there are about 2000 open
> handles, most of them are Event handles, not File handles.  That's higher
> than I'd expect, but not really concerning.
>
>
 Ah, that's useful.  I am using events (python threading.Event).  These
 don't afford any clean up mechanisms on them, so I assume these go away
 when the Python objects that hold them go away.


> Process Explorer, however, shows ~20k open handles per Python process
> running dotest.exe.  It also says that about 2000 of those are the
> process's "own handles."  I'm researching to see what that means.  I
> suspect it means that the process has about ~18k handles to objects owned
> by another process and 2k of ones that it actually owns.
>
> I found this Stack Overflow post, which suggests is may be an
> interaction with using Python subprocess in a loop and having those
> subprocesses work with files that are still open in the parent process, 
> but
> I don't entirely understand the answer:
>
>
> http://stackoverflow.com/questions/16526783/python-subprocess-too-many-open-files
>
>
 Hmm I'll read through that.


> It might be a problem with Python subprocess that's been fixed in a
> newer version.  I'm going to try upgrading from Python 2.7.9 to 2.7.10 to
> see if that makes a difference.
>
>
 Okay, we're on 2.7.10 on latest OS X.  I *think* I'm using Python 2.7.6
 on Ubuntu 14.04.  Checking now... (yes, 2.7.6 on 14.04).  Ubuntu 15.10 beta
 1 is using Python 2.7.10.

 Seems reasonable to check that out.  Let me know what you find out!

 -Todd


> On Mon, Oct 5, 2015 at 12:02 PM, Todd Fiala 
> wrote:
>
>> It's possible.  However, I was monitoring actual open files during
>> the course of the run (i.e. what the kernel thought was open for the 
>> master
>> driver process, which is the only place that makes sense to see leaks
>> accumulate) in both threading and threading-pool (on OS X), and I saw 
>> only
>> the

Re: [lldb-dev] Too many open files

[Adrian McCarthy via lldb-dev]

Adding a printing destructor to threading.Event seems to aggravate timing
problems, causing several tests to fail to make their inferiors and that
seemingly keeps us below the open file limit.  That aside, the destructor
did fire many hundreds of times, so there's not a general problem stopping
all or even most of those to be cleaned up.

The event objects that I'm seeing with the Sysinternals tools are likely
Windows Events that Python creates to facilitate the interprocess
communication.

I'm looking at the ProcessDriver lifetimes now.

On Tue, Oct 6, 2015 at 9:54 AM, Todd Fiala  wrote:

> Okay.
>
> A promising avenue might be to look at how Windows cleans up the
> threading.Event objects.  Chasing that thread might yield why the events
> are not going away (assuming those are the events that are lingering on
> your end).  One thing you could consider doing is patching in a replacement
> destructor for the threading.Event and print something when it fires off,
> verifying that they're really going away from the Python side.  If they're
> not, perhaps there's a retain bloat issue where we're not getting rid of
> some python objects due to some unintended references living beyond
> expectations.
>
> The dosep.py call_with_timeout method drives the child process operation
> chain.  That thing creates a ProcessDriver and collects the results from it
> when done.  Everything within the ProcessDriver (including the event)
> should be cleaned up by the time the call_with_timeout() call wraps up as
> there shouldn't be any references outstanding.  It might also be worth you
> adding a destructor to the ProcessDriver to make sure that's going away,
> one per Python test inferior executed.
>
> On Tue, Oct 6, 2015 at 9:48 AM, Adrian McCarthy 
> wrote:
>
>> Python 2.7.10 made no difference.  I'm dealing with other issues this
>> afternoon, so I'll probably return to this on Wednesday.  It's not critical
>> since there are workarounds.
>>
>> On Tue, Oct 6, 2015 at 9:41 AM, Todd Fiala  wrote:
>>
>>>
>>>
>>> On Mon, Oct 5, 2015 at 3:58 PM, Adrian McCarthy 
>>> wrote:
>>>
 Different tools are giving me different numbers.

 At the time of the error, Windbg says there are about 2000 open
 handles, most of them are Event handles, not File handles.  That's higher
 than I'd expect, but not really concerning.


>>> Ah, that's useful.  I am using events (python threading.Event).  These
>>> don't afford any clean up mechanisms on them, so I assume these go away
>>> when the Python objects that hold them go away.
>>>
>>>
 Process Explorer, however, shows ~20k open handles per Python process
 running dotest.exe.  It also says that about 2000 of those are the
 process's "own handles."  I'm researching to see what that means.  I
 suspect it means that the process has about ~18k handles to objects owned
 by another process and 2k of ones that it actually owns.

 I found this Stack Overflow post, which suggests is may be an
 interaction with using Python subprocess in a loop and having those
 subprocesses work with files that are still open in the parent process, but
 I don't entirely understand the answer:


 http://stackoverflow.com/questions/16526783/python-subprocess-too-many-open-files


>>> Hmm I'll read through that.
>>>
>>>
 It might be a problem with Python subprocess that's been fixed in a
 newer version.  I'm going to try upgrading from Python 2.7.9 to 2.7.10 to
 see if that makes a difference.


>>> Okay, we're on 2.7.10 on latest OS X.  I *think* I'm using Python 2.7.6
>>> on Ubuntu 14.04.  Checking now... (yes, 2.7.6 on 14.04).  Ubuntu 15.10 beta
>>> 1 is using Python 2.7.10.
>>>
>>> Seems reasonable to check that out.  Let me know what you find out!
>>>
>>> -Todd
>>>
>>>
 On Mon, Oct 5, 2015 at 12:02 PM, Todd Fiala 
 wrote:

> It's possible.  However, I was monitoring actual open files during the
> course of the run (i.e. what the kernel thought was open for the master
> driver process, which is the only place that makes sense to see leaks
> accumulate) in both threading and threading-pool (on OS X), and I saw only
> the handful of file handles that I'd expect to  be open - pipes
> (stdout,stderr,stdin) from the main test runner to the inferior test
> runners, the shared libraries loaded as part of the test runner, and (in 
> my
> case, but probably not yours for the configuration), the tcp sockets for
> gathering the test events.  There was no growth, and I didn't see things
> hanging around longer than I'd expect.
>
> The SysInternals process viewer tool is great for this kind of thing -
> glad you're using it.  Once you find out which file handles are getting
> leaked and where they came from, we can probably figure out which part of
> the implementation is leaking it.  I don't *expect* it to be on our side
> given that it's not sh

Re: [lldb-dev] Too many open files

[Adrian McCarthy via lldb-dev]

Python 2.7.10 made no difference.  I'm dealing with other issues this
afternoon, so I'll probably return to this on Wednesday.  It's not critical
since there are workarounds.

On Tue, Oct 6, 2015 at 9:41 AM, Todd Fiala  wrote:

>
>
> On Mon, Oct 5, 2015 at 3:58 PM, Adrian McCarthy 
> wrote:
>
>> Different tools are giving me different numbers.
>>
>> At the time of the error, Windbg says there are about 2000 open handles,
>> most of them are Event handles, not File handles.  That's higher than I'd
>> expect, but not really concerning.
>>
>>
> Ah, that's useful.  I am using events (python threading.Event).  These
> don't afford any clean up mechanisms on them, so I assume these go away
> when the Python objects that hold them go away.
>
>
>> Process Explorer, however, shows ~20k open handles per Python process
>> running dotest.exe.  It also says that about 2000 of those are the
>> process's "own handles."  I'm researching to see what that means.  I
>> suspect it means that the process has about ~18k handles to objects owned
>> by another process and 2k of ones that it actually owns.
>>
>> I found this Stack Overflow post, which suggests is may be an interaction
>> with using Python subprocess in a loop and having those subprocesses work
>> with files that are still open in the parent process, but I don't entirely
>> understand the answer:
>>
>>
>> http://stackoverflow.com/questions/16526783/python-subprocess-too-many-open-files
>>
>>
> Hmm I'll read through that.
>
>
>> It might be a problem with Python subprocess that's been fixed in a newer
>> version.  I'm going to try upgrading from Python 2.7.9 to 2.7.10 to see if
>> that makes a difference.
>>
>>
> Okay, we're on 2.7.10 on latest OS X.  I *think* I'm using Python 2.7.6 on
> Ubuntu 14.04.  Checking now... (yes, 2.7.6 on 14.04).  Ubuntu 15.10 beta 1
> is using Python 2.7.10.
>
> Seems reasonable to check that out.  Let me know what you find out!
>
> -Todd
>
>
>> On Mon, Oct 5, 2015 at 12:02 PM, Todd Fiala  wrote:
>>
>>> It's possible.  However, I was monitoring actual open files during the
>>> course of the run (i.e. what the kernel thought was open for the master
>>> driver process, which is the only place that makes sense to see leaks
>>> accumulate) in both threading and threading-pool (on OS X), and I saw only
>>> the handful of file handles that I'd expect to  be open - pipes
>>> (stdout,stderr,stdin) from the main test runner to the inferior test
>>> runners, the shared libraries loaded as part of the test runner, and (in my
>>> case, but probably not yours for the configuration), the tcp sockets for
>>> gathering the test events.  There was no growth, and I didn't see things
>>> hanging around longer than I'd expect.
>>>
>>> The SysInternals process viewer tool is great for this kind of thing -
>>> glad you're using it.  Once you find out which file handles are getting
>>> leaked and where they came from, we can probably figure out which part of
>>> the implementation is leaking it.  I don't *expect* it to be on our side
>>> given that it's not showing up on a POSIX-y system, but maybe it really is
>>> but isn't in the form of a file handle on the POSIX side.  I should have a
>>> look at the memory growth...
>>>
>>> On Mon, Oct 5, 2015 at 11:41 AM, Adrian McCarthy 
>>> wrote:
>>>
 I'm poking around with some SysInternals tools.  Over the course of
 test run, there are about 602k opens (CreateFiles) and 405k
 closes (CloseFiles) system-wide.

 I'm looking for a way to stop it once the error happens, so I can see
 how many files each process has open.  As it stands, the OS cleans up once
 the error is hit.

 I wonder if it's not a matter of actually leaking open file handles but
 that the closes are happening too late so that we cross the threshold
 shortly before the test runner would have shut everything down.

 On Mon, Oct 5, 2015 at 11:32 AM, Todd Fiala 
 wrote:

> On OS X, I'm also not seeing growth in the --test-runner-name
> threading-pool (the one you were using on Windows).
>
> Perhaps you can dig into if you're experiencing some kind of file leak
> on Windows.  It's possible you're hitting a platform-specific leak?  I
> recall Ed Maste hitting a FreeBSD-only leak in one or more of the python
> 2.7.x releases.
>
> On Mon, Oct 5, 2015 at 11:26 AM, Todd Fiala 
> wrote:
>
>> Hmm, on OS X the file handles seem to be well behaved on the
>> --test-runner-name threading.  I'm not seeing any file handle growth 
>> beyond
>> the file handles I expect to be open.
>>
>> I'll see if the threading-pool behaves differently.  (That is similar
>> to threading but uses the multiprocessing.pool mechanism, at the expense 
>> of
>> me not  being able to catch Ctrl-C at all).
>>
>> It's possible the pool is introducing some leakage at the file level.
>>
>> On Mon, Oct 5, 2015 at 11:20 AM, Todd Fiala 
>>

Re: [lldb-dev] Too many open files

[Adrian McCarthy via lldb-dev]

Different tools are giving me different numbers.

At the time of the error, Windbg says there are about 2000 open handles,
most of them are Event handles, not File handles.  That's higher than I'd
expect, but not really concerning.

Process Explorer, however, shows ~20k open handles per Python process
running dotest.exe.  It also says that about 2000 of those are the
process's "own handles."  I'm researching to see what that means.  I
suspect it means that the process has about ~18k handles to objects owned
by another process and 2k of ones that it actually owns.

I found this Stack Overflow post, which suggests is may be an interaction
with using Python subprocess in a loop and having those subprocesses work
with files that are still open in the parent process, but I don't entirely
understand the answer:

http://stackoverflow.com/questions/16526783/python-subprocess-too-many-open-files

It might be a problem with Python subprocess that's been fixed in a newer
version.  I'm going to try upgrading from Python 2.7.9 to 2.7.10 to see if
that makes a difference.

On Mon, Oct 5, 2015 at 12:02 PM, Todd Fiala  wrote:

> It's possible.  However, I was monitoring actual open files during the
> course of the run (i.e. what the kernel thought was open for the master
> driver process, which is the only place that makes sense to see leaks
> accumulate) in both threading and threading-pool (on OS X), and I saw only
> the handful of file handles that I'd expect to  be open - pipes
> (stdout,stderr,stdin) from the main test runner to the inferior test
> runners, the shared libraries loaded as part of the test runner, and (in my
> case, but probably not yours for the configuration), the tcp sockets for
> gathering the test events.  There was no growth, and I didn't see things
> hanging around longer than I'd expect.
>
> The SysInternals process viewer tool is great for this kind of thing -
> glad you're using it.  Once you find out which file handles are getting
> leaked and where they came from, we can probably figure out which part of
> the implementation is leaking it.  I don't *expect* it to be on our side
> given that it's not showing up on a POSIX-y system, but maybe it really is
> but isn't in the form of a file handle on the POSIX side.  I should have a
> look at the memory growth...
>
> On Mon, Oct 5, 2015 at 11:41 AM, Adrian McCarthy 
> wrote:
>
>> I'm poking around with some SysInternals tools.  Over the course of test
>> run, there are about 602k opens (CreateFiles) and 405k
>> closes (CloseFiles) system-wide.
>>
>> I'm looking for a way to stop it once the error happens, so I can see how
>> many files each process has open.  As it stands, the OS cleans up once the
>> error is hit.
>>
>> I wonder if it's not a matter of actually leaking open file handles but
>> that the closes are happening too late so that we cross the threshold
>> shortly before the test runner would have shut everything down.
>>
>> On Mon, Oct 5, 2015 at 11:32 AM, Todd Fiala  wrote:
>>
>>> On OS X, I'm also not seeing growth in the --test-runner-name
>>> threading-pool (the one you were using on Windows).
>>>
>>> Perhaps you can dig into if you're experiencing some kind of file leak
>>> on Windows.  It's possible you're hitting a platform-specific leak?  I
>>> recall Ed Maste hitting a FreeBSD-only leak in one or more of the python
>>> 2.7.x releases.
>>>
>>> On Mon, Oct 5, 2015 at 11:26 AM, Todd Fiala 
>>> wrote:
>>>
 Hmm, on OS X the file handles seem to be well behaved on the
 --test-runner-name threading.  I'm not seeing any file handle growth beyond
 the file handles I expect to be open.

 I'll see if the threading-pool behaves differently.  (That is similar
 to threading but uses the multiprocessing.pool mechanism, at the expense of
 me not  being able to catch Ctrl-C at all).

 It's possible the pool is introducing some leakage at the file level.

 On Mon, Oct 5, 2015 at 11:20 AM, Todd Fiala 
 wrote:

> Interesting, okay..
>
> This does appear to be an accumulation issue.  You made it most of the
> way through before the issue hit.  I suspect we're leaking file handles.
> It probably doesn't hit the per-process limit on multiprocessing because
> the leaked files get spread across more processes.
>
> (All speculation but does fit the results).
>
> I'll see if I can look into what's there - if we've got an obvious
> leak, I'll take care of it.
>
> On Mon, Oct 5, 2015 at 9:58 AM, Adrian McCarthy 
> wrote:
>
>> Thanks for the ideas.
>>
>> With `--test-runner-name threading-pool`, I get too many open files.
>>
>> With `--test-runner-name multiprocessing-pool`, the suite runs fine.
>>
>> My machine has 40 logical cores.
>>
>> With `--threads=20`:  SUCCESS (and perhaps _faster_).
>>
>> With `--threads=30`:  SUCCESS.
>>
>> With `--threads=36`:  SUCCESS.
>>
>> With `--thread

Re: [lldb-dev] Too many open files

[Adrian McCarthy via lldb-dev]

I'm poking around with some SysInternals tools.  Over the course of test
run, there are about 602k opens (CreateFiles) and 405k
closes (CloseFiles) system-wide.

I'm looking for a way to stop it once the error happens, so I can see how
many files each process has open.  As it stands, the OS cleans up once the
error is hit.

I wonder if it's not a matter of actually leaking open file handles but
that the closes are happening too late so that we cross the threshold
shortly before the test runner would have shut everything down.

On Mon, Oct 5, 2015 at 11:32 AM, Todd Fiala  wrote:

> On OS X, I'm also not seeing growth in the --test-runner-name
> threading-pool (the one you were using on Windows).
>
> Perhaps you can dig into if you're experiencing some kind of file leak on
> Windows.  It's possible you're hitting a platform-specific leak?  I recall
> Ed Maste hitting a FreeBSD-only leak in one or more of the python 2.7.x
> releases.
>
> On Mon, Oct 5, 2015 at 11:26 AM, Todd Fiala  wrote:
>
>> Hmm, on OS X the file handles seem to be well behaved on the
>> --test-runner-name threading.  I'm not seeing any file handle growth beyond
>> the file handles I expect to be open.
>>
>> I'll see if the threading-pool behaves differently.  (That is similar to
>> threading but uses the multiprocessing.pool mechanism, at the expense of me
>> not  being able to catch Ctrl-C at all).
>>
>> It's possible the pool is introducing some leakage at the file level.
>>
>> On Mon, Oct 5, 2015 at 11:20 AM, Todd Fiala  wrote:
>>
>>> Interesting, okay..
>>>
>>> This does appear to be an accumulation issue.  You made it most of the
>>> way through before the issue hit.  I suspect we're leaking file handles.
>>> It probably doesn't hit the per-process limit on multiprocessing because
>>> the leaked files get spread across more processes.
>>>
>>> (All speculation but does fit the results).
>>>
>>> I'll see if I can look into what's there - if we've got an obvious leak,
>>> I'll take care of it.
>>>
>>> On Mon, Oct 5, 2015 at 9:58 AM, Adrian McCarthy 
>>> wrote:
>>>
 Thanks for the ideas.

 With `--test-runner-name threading-pool`, I get too many open files.

 With `--test-runner-name multiprocessing-pool`, the suite runs fine.

 My machine has 40 logical cores.

 With `--threads=20`:  SUCCESS (and perhaps _faster_).

 With `--threads=30`:  SUCCESS.

 With `--threads=36`:  SUCCESS.

 With `--threads=38`:  TOO MANY OPEN FILES.

 So we're right at the edge.  I'll keep investigating.

 So it seems we're on the bleeding edge.


 On Fri, Oct 2, 2015 at 5:38 PM, Todd Fiala 
 wrote:

> (swapped out the lldb list for the newer one)
>
> On Fri, Oct 2, 2015 at 5:37 PM, Todd Fiala 
> wrote:
>
>> Hmm, sounds suspicious.
>>
>> Can you try running the tests with two options and see if you get
>> different results?
>>
>> # should be equivalent for the default on Windows, thus should match
>> your above results.  This one uses a thread per worker queue.
>> --test-runner-name threading-pool
>>
>> # should use a different test runner.  This one uses a process per
>> worker queue.
>> --test-runner-name multiprocessing-pool
>>
>> Aside from that, it seems like the total number of open files is
>> exceeding some process/system maximum, which sounds like (maybe) we're
>> leaking files somewhere.  Not enough info yet to guess where that might 
>> be
>> coming in from, but maybe a part of the test runner isn't closing files
>> somewhere.
>>
>> The other thing you can try is reducing the total number of threads,
>> with:
>> --threads {some-number-lower-than-your-total-number-of-logical-cores}
>>
>> in the event that your machine has a mongo number of logical cores,
>> and perhaps it is trying to do too much.  (In that case, the
>> multiprocessing-pool runner might actually help).
>>
>> Thanks!
>>
>> -Todd
>>
>> On Fri, Oct 2, 2015 at 5:31 PM, Adrian McCarthy 
>> wrote:
>>
>>> When running LLDB tests on Windows, I started getting a "too many
>>> open files" error from Python.  I used git bisect to narrow it down to 
>>> this
>>> revision:
>>>
>>> http://llvm.org/viewvc/llvm-project?view=revision&revision=249182
>>>
>>> The error output is:
>>>
>>> Command invoked: D:\src\Python-2.7.9\PCbuild\python_d.exe
>>> D:\src\llvm\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
>>> D:/src/llvm/build/ninja/bin/lldb.exe -s
>>> D:/src/llvm/build/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS
>>> --enable-crash-dialog -C D:\src\llvm\build\ninja_release\bin\clang.exe
>>> --inferior -p TestRecursiveTypes.py D:\src\llvm\llvm\tools\lldb\test
>>> --event-add-entries worker_index=7:int
>>> 384 out of 400 test suites processed - TestRecursiveTypes.py
>>>  

Re: [lldb-dev] Too many open files

[Adrian McCarthy via lldb-dev]

Thanks for the ideas.

With `--test-runner-name threading-pool`, I get too many open files.

With `--test-runner-name multiprocessing-pool`, the suite runs fine.

My machine has 40 logical cores.

With `--threads=20`:  SUCCESS (and perhaps _faster_).

With `--threads=30`:  SUCCESS.

With `--threads=36`:  SUCCESS.

With `--threads=38`:  TOO MANY OPEN FILES.

So we're right at the edge.  I'll keep investigating.

So it seems we're on the bleeding edge.


On Fri, Oct 2, 2015 at 5:38 PM, Todd Fiala  wrote:

> (swapped out the lldb list for the newer one)
>
> On Fri, Oct 2, 2015 at 5:37 PM, Todd Fiala  wrote:
>
>> Hmm, sounds suspicious.
>>
>> Can you try running the tests with two options and see if you get
>> different results?
>>
>> # should be equivalent for the default on Windows, thus should match your
>> above results.  This one uses a thread per worker queue.
>> --test-runner-name threading-pool
>>
>> # should use a different test runner.  This one uses a process per worker
>> queue.
>> --test-runner-name multiprocessing-pool
>>
>> Aside from that, it seems like the total number of open files is
>> exceeding some process/system maximum, which sounds like (maybe) we're
>> leaking files somewhere.  Not enough info yet to guess where that might be
>> coming in from, but maybe a part of the test runner isn't closing files
>> somewhere.
>>
>> The other thing you can try is reducing the total number of threads, with:
>> --threads {some-number-lower-than-your-total-number-of-logical-cores}
>>
>> in the event that your machine has a mongo number of logical cores, and
>> perhaps it is trying to do too much.  (In that case, the
>> multiprocessing-pool runner might actually help).
>>
>> Thanks!
>>
>> -Todd
>>
>> On Fri, Oct 2, 2015 at 5:31 PM, Adrian McCarthy 
>> wrote:
>>
>>> When running LLDB tests on Windows, I started getting a "too many open
>>> files" error from Python.  I used git bisect to narrow it down to this
>>> revision:
>>>
>>> http://llvm.org/viewvc/llvm-project?view=revision&revision=249182
>>>
>>> The error output is:
>>>
>>> Command invoked: D:\src\Python-2.7.9\PCbuild\python_d.exe
>>> D:\src\llvm\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
>>> D:/src/llvm/build/ninja/bin/lldb.exe -s
>>> D:/src/llvm/build/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS
>>> --enable-crash-dialog -C D:\src\llvm\build\ninja_release\bin\clang.exe
>>> --inferior -p TestRecursiveTypes.py D:\src\llvm\llvm\tools\lldb\test
>>> --event-add-entries worker_index=7:int
>>> 384 out of 400 test suites processed - TestRecursiveTypes.py
>>>   Traceback (most recent call last):
>>>   File "D:/src/llvm/llvm/tools/lldb/test/dotest.py", line 1457, in
>>> 
>>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 1355, in main
>>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 968, in
>>> walk_and_invoke
>>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 1095, in
>>> 
>>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 889, in
>>> threading_test_runner_pool
>>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 774, in
>>> map_async_run_loop
>>>   File "D:\src\Python-2.7.9\Lib\multiprocessing\pool.py", line 558, in
>>> get
>>> OSError: [Errno 24] Too many open files
>>> [77809 refs]
>>> ninja: build stopped: subcommand failed.
>>>
>>>
>>> Any clue what might have caused this or what can be done to fix it?
>>>
>>> It's Friday afternoon, so there's no urgency from my perspective.  I'll
>>> probably get back to this on Monday morning.
>>>
>>> Thanks,
>>> Adrian McCarthy
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Portable tests that create threads

[Adrian McCarthy via lldb-dev]

I don't think that's a good plan.  It's the implementation of std::thread
that created the thread pool.  It's quite possible that it then
re-purposing thread pool threads as user threads.  This gets into
implementation details that we'd have to figure out and which could change.

Even with the equivalent of a single-threaded Hello World program, Zach and
I are seeing a different number of threads on different versions of Windows.

I'm in favor of having the inferior somehow designate the threads it's
intentionally creating (or causing to be created) and having the tests look
for those designations.  I like the naming idea.


On Wed, Sep 2, 2015 at 1:17 PM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> That might work, on Windows I think we could identify this by looking
> for ntdll.dll!TppWorkerThread() in the stack frame.  This might not be
> exactly the same across OS versions, but we could handle all cases as new
> ones are discovered.
>
> We would have to make sure that all developers are educated on the
> distinction, so that only user threads are queried in future tests, but it
> has the advantage of not needing any modifications to the inferior
>
> On Wed, Sep 2, 2015 at 1:06 PM Greg Clayton  wrote:
>
>> One idea is add the ability to discover which of any of the current
>> threads are or are not user created. This might help us.
>>
>> On MacOSX, the main thread would always be considered user created, and
>> any other thread, it is quite easy to tell. User created threads could be
>> ones whose bottom stack frame is "thread_start"
>>
>> 
>> frame #8: 0x7fff9b47c41d libsystem_pthread.dylib thread_start + 13
>>
>> Where OS created threads have their last frames in "start_wqthread" or
>> "_dispatch_mgr_thread":
>>
>> ...
>> frame #2: 0x7fff9b47c40d libsystem_pthread.dylib start_wqthread +
>> 13
>>
>> or:
>>
>> ...
>> frame #2: 0x7fff9c298a6a libdispatch.dylib _dispatch_mgr_thread +
>> 52
>>
>>
>> So it might be easy to add API to SBThread like:
>>
>> bool
>> SBThread::IsUserCreated();
>>
>> Then we could teach the tests to filter out any threads that are not user
>> created?
>>
>> Greg
>>
>>
>> > On Sep 2, 2015, at 12:31 PM, Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >
>> > Historically the pattern for tests that need to test situations
>> involving threads has been to write the tests using pthreads, and then a
>> common pattern on the python side of the test is to assert that the actual
>> number of threads equals the expected number of threads.
>> >
>> > To deal with the pthread portability issue, I ported most of these
>> tests over to std::threads, but there is still another issue with them.
>> >
>> > On Windows we can't assume anything about the number of threads in a
>> program.  For example, a single-threaded hello world program actually has 3
>> threads, 2 of which are reserved for use by the operating system.  And the
>> fact that there's 2 is just arbitrary, that might not remain the same
>> between compiler versions, operating system versions, etc.  And to make
>> matters worse it might not even remain constant through the life of the
>> program (the assumption just being that we cannot make any assumptions,
>> since we don't control the threads).
>> >
>> > So I need to find a way to write these tests portably.
>> >
>> > Do all platforms have a way to assign a thread a name?  Looking in
>> Host/*/ThisThread.cpp, it seems:
>> >
>> > 1) Linux and MacOSX inferiors can use pthread_setname_np
>> > 2) FreeBSD inferiors can use pthread_set_name_np
>> > 3) Windows inferiors can raise a magic exception which the debugger is
>> expected to recognize
>> >
>> > Based on this, it seems that one possible way to write these tests
>> portably is to have the test inferiors assign names to the threads, and
>> have the tests index the threads by name instead of by ordinal.
>> >
>> > Does anyone have any thoughts on this or other possible approaches?
>> >
>> > I really would like to avoid having different inferiors or different
>> tests for all of this functionality, as it will be very easy to get out of
>> sync.
>> > ___
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] TestRdarXXXXXX

[Adrian McCarthy via lldb-dev]

There's also test\expression_command\issue_11588, which is especially
confusing because the comments and symbols in the test are actually
numbered 11581.

On Fri, Aug 14, 2015 at 11:58 AM, Enrico Granata via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
> On Aug 14, 2015, at 11:50 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> There are a bunch of tests in the tree that are named after Rdars.  As a
> result, it's not clear to anyone outside of Apple what these are supposed
> to be testing so it diminishes their usefulness and increases our
> maintenance burden since it's impossible to know if it is an issue that we
> should fix, or if it is something platform specific.
>
> Would it be possible for someone to rename these tests to something more
> descriptive?
>
>
> I think it’s a good idea (renaming the tests)
> I can definitely take on some of the renaming effort
>
>
> Here is a list of some of the ones I've found:
>
> lldb/test/functionalities/data_formatter:
> + rdar-3534688
> + rdar-9973865
> + rdar-9973992
> + rdar-9974002
> + rdar-10449092
> + rdar-10642615
> + rdar-10887661
> + rdar-11086338
> + rdar-11628688
> + rdar-11773899
> + rdar-11988289
> + rdar-12437442
> + rdar-12529957
> + rdar-13338477
>
>
> These are most certainly all of my own making…… *sigh*
>
> lldb/test/python_api:
> + rdar-12481949
>
> lldb/test/lang/cpp:
> + rdar12991846
>
> lldb/test/functionalities/command_script/import:
> + rdar-12586188
>
> lldb/test/lang/objc:
> + rdar-9691614
> + rdar-10967107
> + rdar-11355592
> + rdar-12408181
>
> For those tests which it is not possible to share more details about what
> the test is fixing, can I request those tests be moved out of tree?
>
>
> Let us not do that if at all possible
> Renaming is the correct avenue here
>
> "If the test contents can be shared publicly, then so can a reasonable
> test name” seems a sane rule of thumb
>
> I assume Apple already has an internal test suite for this reason
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> Thanks,
> *- Enrico*
> 📩 egranata@.com ☎️ 27683
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev