Summary:
This breaks when using a symlink from llvm/tools/lldb to the lldb source
tree, instead of cloning directly as a child. With this change, we can
build properly, even when using links.
Reviewers: dawn, brucem, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14089
llvm-svn: 251530
GCC produce a lot of strict-aliasing warning for the LLDB codebase
what makes reading the compile output very difficult. This change
disable these warnings to reduce the noise as we already ignore them.
We should consider re-enabling the warning if we fix all (or most)
strict-aliasing violation first.
Differential revision: http://reviews.llvm.org/D13981
llvm-svn: 251107
Newer versions of CMake include a "smarter" FindLibxml2 package.
In theory this is a good thing, but on Windows it's now smart
enough to find the version that comes with Gnuwin32, which doesn't
appear to be a valid libxml2 distribution. Or at the very least,
LLDB currently uses some header files from libxml2 that are not
part of this distribution.
Nobody on Windows is using any of this functionality right now
anyway, so just disable it.
llvm-svn: 250709
Summary:
I see a lot of following warnings in LLDBWrapPython.cpp while building with gcc 4.9 on Linux.
"warning: cast from type ‘const char*’ to type ‘char*’ casts away qualifiers [-Wcast-qual]"
Is it ok to add -Wno-cast-qual for this file in cmake for gcc. This option seems to be already present
for autotool case.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13719
llvm-svn: 250380
Adding the following flag to a cmake line:
-DLLDB_EXPORT_ALL_SYMBOLS=TRUE
will cause all symbols to be exported from liblldb. This enables the llvm
backtrace mechanism to see and report backtrace symbols properly when using
(lldb) log enable --stack ...
Prior to this change, only the SB API symbols would show up on Linux and other
systems that use a public-symbols-based backtrace lookup mechanism.
log enable --stack ... is a very handy, quick way to understand the flow
of how some log lines are getting hit within lldb without having to hook
up a top-level debugger over your current debug session.
llvm-svn: 250299
Summary:
This is Darwin only.
The symbol defined by ${LLDB_VERS_GENERATED_FILE} is used by
source/lldb.cpp, so anything that uses lldb.cpp (which is in
lldbBase) should also have the generated symbol. This means
that the entire process can be centralized within source/CMakeLists.txt
where lldbBase is constructed.
Additionally, the custom command should have dependencies on the
project file as well as the generation script so that if either
changes, the version file is correctly re-generated and everything
is re-linked appropriately.
* cmake/LLDBDependencies.cmake: Remove everything related to
the generated version file from here.
* source/CMakeLists.txt: On Darwin, add the generated version
file to the sources that make up lldbBase. Also, create a
custom target and make lldbBase depend on it to re-generate
the generated file as needed.
* source/API/CMakeLists.txt: Don't need to build the generated
version file here or use it to control linking against swig_wrapper.
* tools/lldb-server/CMakeLists.txt: Likewise.
Reviewers: dawn, sas, clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13552
llvm-svn: 249806
Summary:
Previously CMake would display messages like these:
```
-- LLDB Found PythonExecutable: $<$<CONFIG:Debug>:C:/Projects/Python-2.7.9-bin/x64/python_d.exe>$<$<NOT:$<CONFIG:Debug>>:C:/Projects/Python-2.7.9-bin/x64/python.exe>
-- LLDB Found PythonLibs: $<$<CONFIG:Debug>:C:/Projects/Python-2.7.9-bin/x64/libs/python27_d.lib>$<$<NOT:$<CONFIG:Debug>>:C:/Projects/Python-2.7.9-bin/x64/libs/python27.lib>
-- LLDB Found PythonDLL: $<$<CONFIG:Debug>:C:/Projects/Python-2.7.9-bin/x64/python27_d.dll>$<$<NOT:$<CONFIG:Debug>>:C:/Projects/Python-2.7.9-bin/x64/python27.dll>
```
This patch makes the messages look like this:
```
-- LLDB Found PythonExecutable: C:/Projects/Python-2.7.9-bin/x64/python.exe and C:/Projects/Python-2.7.9-bin/x64/python_d.exe
-- LLDB Found PythonLibs: C:/Projects/Python-2.7.9-bin/x64/libs/python27.lib and C:/Projects/Python-2.7.9-bin/x64/libs/python27_d.lib
-- LLDB Found PythonDLL: C:/Projects/Python-2.7.9-bin/x64/python27.dll and C:/Projects/Python-2.7.9-bin/x64/python27_d.dll
```
I've also added checks to ensure the messages are actually accurate, as in check that the files actually exist before claiming they've been found. If any of the files are missing Python integration will be disabled for the build.
Patch by Vadim Macagon. Thanks!
Reviewers: brucem, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13520
llvm-svn: 249671
Summary: We were missing the symbol for the version number.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13271
llvm-svn: 249434
Summary:
Previously `CMAKE_BUILD_TYPE` was used to determine whether to link in `python27.lib` or `python27_d.lib`, unfortunately this only works reliably when using a CMake generator that generates a single build configuration (e.g. Ninja). The Visual Studio CMake generator generates four build configurations at once (`Debug`, `Release`, `RelWithDebInfo`, `MinSizeRel`), so if `CMAKE_BUILD_TYPE` is set to `Debug` all four build configurations end up linking in `python27_d.lib`, this is clearly undesirable.
To ensure that the correct Python lib is used for each build configuration the value of `PYTHON_LIBRARY` is now determined using generator expressions that evaluate to either the debug or release Python lib. The values of `PYTHON_EXECUTABLE` and `PYTHON_DLL` are now likewise determined using generator expressions.
Note that these changes only apply to the Windows build.
Patch by Vadim Macagon. Thanks!
Reviewers: zturner, brucem
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D13234
llvm-svn: 248991
Summary:
This switches the decision as to whether or not to lldb-server should
be built to check the same flag that was added that controls whether
or not it is added as a dependency to the 'lldb' target.
It also sets that flag on FreeBSD to maintain parity with the existing
build configuration / situation on FreeBSD.
Reviewers: labath, emaste, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12925
llvm-svn: 247913
The Go runtime schedules user level threads (goroutines) across real threads.
This adds an OS plugin to create memory threads for goroutines.
It supports the 1.4 and 1.5 go runtime.
Differential Revision: http://reviews.llvm.org/D5871
llvm-svn: 247852
Ncurses related symbols can either all be found in libnurses or split
between libncurses and libtinfo. The main LLVM cmake scripts look for the
setupterm symbol and stores the library that has it in TERMINFO_LIBS. This
covers the split and unified ncurses case. LLDB uses symbols that can end
up in libtinfo so this library should be pulled in if it is found.
There is still an exotic case left where LLDB is configured with
-DLLDB_DISABLE_CURSES=NO and LLVM with -DLLVM_ENABLE_TERMINFO=NO but
misconfigurations will always be possible. Possibly a diagnostic could be
added for that.
This fixes bug 24693.
Differential Revision: http://reviews.llvm.org/D12672
Patch by Jeremi Piotrowski
llvm-svn: 247842
ninja lldb now does the following:
* forces the python post-build step to fire, which sets up the python lldb module properly.
* on Darwin and Linux, requires the lldb-server target to be built.
* on Darwin, requires the debugserver target to be built.
See http://reviews.llvm.org/D12899 for details.
llvm-svn: 247810
Summary:
* cmake/LLDBDependencies.cmake: elf-core is already included
globally in LLDB_USED_LIBS, so it doesn't need to be re-added
on individual platforms.
* lib/Makefile: elf-core is linked on each platform, so move it
to the global list of used libraries.
* source/Plugins/Makefile: elf-core is built on each platform, so
move it to the global list of things to build.
Reviewers: clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12762
llvm-svn: 247366
Summary:
We currently link to this on all platforms, so don't need to re-include
it into the LLDB_USED_LIBS. Also don't need to special case building
it for every supported platform.
Reviewers: clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12756
llvm-svn: 247284
Summary:
This should be a mandatory build process going forward, if Python
is enabled. The longer term desire is to remove the old shell
scripts entirely.
Reviewers: zturner, clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12667
llvm-svn: 246979
Summary:
This was previously only established within debugserver, but
there is a use of the VLA extension in source/Host/macosx/Symbols.cpp,
so ignore this warning globally.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12515
llvm-svn: 246605
Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex)
This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on
The advantages of this are:
a) language formatters only get created when they might apply
b) formatters for a language are clearly owned by the matching language plugin
The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager
In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters
No formatters are moved as part of this change, so practically speaking this is NFC
llvm-svn: 246568
With static linking lldb-server crashes in platform mode when
tries to listen on localhost:5432 on the android build bot.
This reverts commit 3ea861707dec8423746679ff496e4fd03255d4cf.
llvm-svn: 242401
Summary:
The accept4 syscall is missing on older ARM Android kernels, and the accept()
call is implemented with the accept4 syscall, so we'll need to call the accept
syscall directly.
Reviewers: vharron, tberghammer, labath
Subscribers: ovyalov, chaoren, labath, tberghammer, aemerson, lldb-commits
Differential Revision: http://reviews.llvm.org/D10887
llvm-svn: 242319
Summary:
This commit moves the Windows DyanamicLoader to the common DynamicLoader
directory. This is required to remote debug Windows targets.
This commit also initializes the Windows DYLD plugin in
SystemInitializerCommon (similarly to both POSIX and MacOSX DYLD
plugins) so that we can automatically instantiate this class when
connected to a windows process.
Test Plan: Build.
Reviewers: zturner
Subscribers: lldb-commits, abdulras
Differential Revision: http://reviews.llvm.org/D10882
llvm-svn: 241697
Chaoren Lin