Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

[Pavel Labath via lldb-dev]

Hi Emre,

I have to say I'm pretty sceptical about this approach, for all the
reasons that Jim already mentioned. Making it so that lldb pretends the
other shared libraries don't exist (which is what I assume your
prototype does) is fairly easy, but it does create a very long tail of
"feature X does not work in this mode" problems (my app crashed in a
third-party library -- maybe because I passed it a wrong argument -- but
I cannot even unwind into my code to see what I passed).

It's the fixing these problems that will make the solution very complicated.

On 08/05/2020 22:21, Jim Ingham via lldb-dev wrote:
> Note, if you are reading the binaries out of memory from the device, and
> don’t have local symbols, things go much more slowly.  gdb-remote is NOT
> a high bandwidth protocol, and fetching all the symbols through a series
> of memory reads is pretty slow.  lldb does have a setting to control
> what you do with binaries that don’t exist on the host
> (target.memory-module-load-level) that controls this behavior.  But it
> just deals with what we do and don’t read and makes no attempt to
> ameliorate the fallout from having a reduced view of the symbols in the
> program.
We don't load modules from memory on android (with elf that doesn't even
work right now in lldb). We download files directly via the adb
protocol, which is much faster than gdb-remote's qFile. So I'm afraid
the problem is going to be more complicated than that.


pl
___
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]

Ug.  After a rebase, this problem has again resurfaced for me.

* PATH has only C:\Python36
* cmake version 3.15.19101501-MSVC_2
* cmake -GNinja -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
-DCMAKE_BUILD_TYPE=Debug -DLLDB_TEST_DEBUG_TEST_CRASHES=1
-DPYTHON_HOME=C:\Python36
-DLLDB_PYTHON_HOME=C:\Python36 -DPython3_ROOT_DIR=C:\Python36
-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;debuginfo-tests"

Yet when linking LLDB, it goes looking at the Python 3.7 installation that
comes with Visual Studio.  That wouldn't be much of a problem unless you're
trying to build debug, which I am.  The VS version, doesn't come with debug
versions of the interpreter libraries, so the link fails:

[1/7] Linking CXX shared library bin\liblldb.dll
FAILED: bin/liblldb.dll lib/liblldb.lib
cmd.exe /C "cd . && "C:\Program Files (x86)\Microsoft Visual
Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe"
-E vs_link_dll --intdir=tools\lldb\source\API\CMakeFiles\liblldb.dir
--rc=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x64\rc.exe
--mt=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x64\mt.exe --manifests  --
C:\PROGRA~2\MICROS~1\2019\PROFES~1\VC\Tools\MSVC\1424~1.283\bin\Hostx64\x64\link.exe
/nologo @CMakeFiles\liblldb.rsp  /out:bin\liblldb.dll
/implib:lib\liblldb.lib /pdb:bin\liblldb.pdb /dll /version:11.0
/machine:x64 /debug /INCREMENTAL   && cd ."
LINK Pass 1: command
"C:\PROGRA~2\MICROS~1\2019\PROFES~1\VC\Tools\MSVC\1424~1.283\bin\Hostx64\x64\link.exe
/nologo @CMakeFiles\liblldb.rsp /out:bin\liblldb.dll
/implib:lib\liblldb.lib /pdb:bin\liblldb.pdb /dll /version:11.0
/machine:x64 /debug /INCREMENTAL /MANIFEST
/MANIFESTFILE:tools\lldb\source\API\CMakeFiles\liblldb.dir/intermediate.manifest
tools\lldb\source\API\CMakeFiles\liblldb.dir/manifest.res" failed (exit
code 1104) with the following output:
LINK : fatal error LNK1104: cannot open file 'python37_d.lib'
ninja: build stopped: subcommand failed.

It looks like Cmake has added several more hints for finding Python
.  I'm
trying now with -DPython3_FIND_REGISTRY=LAST.

I miss hermetic builds.

On Thu, Feb 27, 2020 at 11:33 AM Adrian McCarthy 
wrote:

> >  This was all fixed in CMake 3.12.
>
> For some definitions of "all fixed." ;-)
>
> It seems weird to me that FindPython3 found the VS-distributed Python,
> which isn't mentioned anywhere in the environment block, and that it chose
> that one over the Python 3 installation that was in the path and that
> included the interpreters and all of the corresponding libraries.
>
> >  With FindPython{2,3} you know you'll have a matching interpreter and
> library.
>
> The build failure was that the Python distributed in VS does not have a
> debug version of the library (python37_d.lib), so you don't actually get a
> matching interpreter and library for debug builds.
>
> It's also not clear whether LLVM was consistently using the Python found
> the old way.  My generated build.ninja file seemed to be using both
> versions inconsistently to run lit tests and the like.
>
> Anyway, thanks for the explanations.  I've LGTMed your patch, which should
> eliminate future surprises when something else smuggles yet another version
> of Python onto a machine.
>
> On Thu, Feb 27, 2020 at 11:14 AM Jonas Devlieghere 
> wrote:
>
>> So to make my previous explanation more concrete:
>>
>> On Thu, Feb 27, 2020 at 11:05 AM Jonas Devlieghere 
>> wrote:
>>
>>>
>>>
>>> On Thu, Feb 27, 2020 at 10: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