Re: [lldb-dev] www/architecture.html
That sounds fair, we should definitely make sure we're on the same page. I've put up D34872 to better document state of affairs after the recent refactors. I am a bit reluctant to try to document the "direction we're heading towards" because that is something where I am still developing clarity, and I believe we will have many discussions about that before it finalizes. However, I can try to explain where I am coming from: The way I see it, we have two main products coming out of the lldb_private namespace: liblldb and lldb-server. I'd like to get their dependencies separated (e.g. being able to build lldb-server without linking in the pretty printers, or maybe even without having clang checked out). However, that is still quite far off. Right now I am looking at just three modules: Utility, Host and Core. I would define Utility as a "semi-random collection of simple algorithms and data structures that have nothing or very little to do with debugging". They shouldn't depend on anything else. Host is "algorithms for doing this to the host that are very likely to be full of ifdefs". To achieve this objective they can use the algorithms and data structures from Utility. I deliberately omitted "data structures" from here, as those need not be defined in Host. For example for getting information about the running process the structure that describes a running process can be in Utility, while the getProcessInfo can be in host. I personally wouldn't be too strict here and say that if a data structure is already in Host, and nothing in Utility needs it, then it can stay there, but I thing Zachary feels differently here. I believe Host shouldn't depend on anything except Utility (unless we invent a new module which will be shared between liblldb and lldb-server) Core is the one that puzzles me the most. I am not really sure how to describe it. What is clear to me is that it contains (or used to contain, now we've moved a lot of it out, but still some remain) a lot of low-level stuff that is used by lldb-server (State, ArchSpec), and a lot of high level stuff which are not used (and probably never will be used) in lldb-server (Debugger, ValueObject). So right now, I am trying to move all of the low level things outside of there and hope that what remains will crystalize into some form. I'd be interested to hear your opinion of what Core should be. Other modules seem to have a fairly well defined purpose. I am not planning on changing it or moving large chunks of them, among other reasons because I am not familiar with enough with their inner workings. (***) I think some of their edges could be reversed, but that's not something I plan to do now, nor I have an idea of how exactly they should be. The main thing how the current situation differs from the state I described is the Host module, so that's why I am focusing on it now. I want to kill it's outgoing edges, and I started the one pointing at Core. There were a couple of easy ones, which I've solved by moving things to Utility (because it made sense according to the definitions above). But now a couple of others remain, which are not so obvious, and I am planning to open separate discussions about them (one of them is about ArchSpec, but I don't want to say anything about that until I go back and re-read what was said previously). I am not sure that this provides the clear intention that you were asking for, but I hope it at least explains what I am presently doing. I'd like to hear your thoughts on that. pavel *** Actually there is one more: Process/gdb-remote. I don't like how large chunks of client and server functionality are in the same module (although it is also nice to have them close together). I have some ideas about what to do there, but I am not going to start implementing them any time soon. On 29 June 2017 at 18:36, Jim Ingham via lldb-dev wrote: > The recent and not so recent moves from Core to Utility, etc. have left the > information in this file stale. It was last updated in 2013... > > Can one of the people doing this work (Zachary, Pavel...) take a look at this > and bring it up to date, and maybe make more clear the current intentions for > the layout? That would be helpful for folks coming to work on the project, > and also to give us a common understanding of the structure we're working > towards. > > Thanks! > > Jim > > ___ > 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] Python scripting in Windows LLDB
Python support on Windows is much more problematic than support on something
like MacOS or Linux. The python you use when you run lldb must be the same
python used when you build it. Bad things happen – warnings, crashes, etc –
when you use a different rev of the dll/so or the library directory (which
contains dlls/sos) than what was used when building lldb. MacOS and various
Linux distros ship with a fixed version of python, so lldb can be built with
that version. Windows doesn’t have a default python, so you need to make sure
that your user has the same version of python that lldb was built with.
For the Hexagon tools, we ship the python dll/so and the library directory that
we built with. We use 3.5.1 on Windows, and 2.7.8 on Linux. On Linux, we set
RPATH to ../lib, so lldb/liblldb.so can find libpython.so. On both, we set a
cmake variable LLDB_DEFAULT_PYTHONHOME, and use it when initializing python to
point lldb to the path where our python library is installed. This code isn’t
upstreamed, but I can upstream it if the community would like it.
Another issue on Windows is the python installation integrity check in
cmake/modules/LLDBConfig.cmake. It checks to see if python is installed
correctly like this:
if (NOT (PYTHON_DEBUG_EXE AND PYTHON_RELEASE_EXE AND PYTHON_DEBUG_LIB AND
PYTHON_RELEASE_LIB AND PYTHON_DEBUG_DLL AND PYTHON_RELEASE_DLL))
message("Python installation is corrupt. Python support will be disabled
for this build.")
set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
return()
endif()
If you don’t have the debug version of python installed (as is the case on our
builders), this check will fail, and python will be turned off. Internally, I
break this check up into debug and release checks, based on the value of
CMAKE_BUILD_TYPE. I also don’t check for the release dll, because our builders
don’t have that. I can also upstream this if the community is interested.
Ted
--
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 Jamie
Madill via lldb-dev
Sent: Thursday, June 29, 2017 10:30 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] Python scripting in Windows LLDB
A ping for this regression - Ted Woodward seems to have had a patch for fixing
broken Windows scripting support but the 5.0.0 snapshot release didn't have the
fix. Is it possible to land that patch for the next snapshot?
This is currently breaking LLDB Visual Studio Code integration on Windows (for
context, see https://github.com/vadimcn/vscode-lldb/issues/37 .)
Thanks!
Jamie
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Python scripting in Windows LLDB
On Fri, Jun 30, 2017 at 12:39 PM Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Python support on Windows is much more problematic than support on > something like MacOS or Linux. The python you use when you run lldb must be > the same python used when you build it. Bad things happen – warnings, > crashes, etc – when you use a different rev of the dll/so or the library > directory (which contains dlls/sos) than what was used when building lldb. > This is no longer true right? That was one of the major drivers behind moving to Python 3.5. All that matters is a) The *build configuration* matches (if LLDB was built against Python debug, you must have debug libraries available) b) The *architecture* matches (if it's an x64 build of LLDB, you need x64 Python libraries) c) The *version* is 3.5 or higher. Aside from that it shouldn't matter ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Python scripting in Windows LLDB
I’ve seen crashes on Linux when building with 2.7.6 and using the 2.7.3 .so/library directory, so I’m not willing to say building on Windows with 3.6.1 and using the 3.5.2 dll/library directory will work. Python has never been very forgiving when using a different setup than what you built with. My point with that statement is you’ve got to make sure the runtime environment matches the build environment, something harder to do on Windows where there is no default runtime environment. -- 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: Friday, June 30, 2017 3:05 PM To: Ted Woodward ; Jamie Madill ; lldb-dev@lists.llvm.org Subject: Re: [lldb-dev] Python scripting in Windows LLDB On Fri, Jun 30, 2017 at 12:39 PM Ted Woodward via lldb-dev mailto:lldb-dev@lists.llvm.org> > wrote: Python support on Windows is much more problematic than support on something like MacOS or Linux. The python you use when you run lldb must be the same python used when you build it. Bad things happen – warnings, crashes, etc – when you use a different rev of the dll/so or the library directory (which contains dlls/sos) than what was used when building lldb. This is no longer true right? That was one of the major drivers behind moving to Python 3.5. All that matters is a) The build configuration matches (if LLDB was built against Python debug, you must have debug libraries available) b) The architecture matches (if it's an x64 build of LLDB, you need x64 Python libraries) c) The version is 3.5 or higher. Aside from that it shouldn't matter ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Python scripting in Windows LLDB
On Fri, Jun 30, 2017 at 1:34 PM Ted Woodward wrote: > I’ve seen crashes on Linux when building with 2.7.6 and using the 2.7.3 > .so/library directory, so I’m not willing to say building on Windows with > 3.6.1 and using the 3.5.2 dll/library directory will work. Python has never > been very forgiving when using a different setup than what you built with. > Well, never prior to 3.5 anyway. That was literally one of the entire points of requiring 3.5+ on Windows. Python for Windows post 3.5 uses the Universal CRT, which is forwards compatible. More information here: http://stevedower.id.au/blog/building-for-python-3-5/ I can't speak to the issue of 2.7.6 vs 2.7.3 on Linux you experienced, but on Windows the officially supported position of the Python project is that you can install any version of Python post 3.5 and it "just works". ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Python scripting in Windows LLDB
Note that building with 3.6.x and using 3.5.x won't work, but any of 3.5.x revisions should be compatible between themselves. On Fri, Jun 30, 2017 at 1:41 PM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > On Fri, Jun 30, 2017 at 1:34 PM Ted Woodward > wrote: > >> I’ve seen crashes on Linux when building with 2.7.6 and using the 2.7.3 >> .so/library directory, so I’m not willing to say building on Windows with >> 3.6.1 and using the 3.5.2 dll/library directory will work. Python has never >> been very forgiving when using a different setup than what you built with. >> > Well, never prior to 3.5 anyway. That was literally one of the entire > points of requiring 3.5+ on Windows. Python for Windows post 3.5 uses the > Universal CRT, which is forwards compatible. More information here: > http://stevedower.id.au/blog/building-for-python-3-5/ > > I can't speak to the issue of 2.7.6 vs 2.7.3 on Linux you experienced, but > on Windows the officially supported position of the Python project is that > you can install any version of Python post 3.5 and it "just works". > > > ___ > 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
