2015-03-18 06:51:21 +08:00
|
|
|
add_custom_target(LLDBUnitTests)
|
|
|
|
|
set_target_properties(LLDBUnitTests PROPERTIES FOLDER "LLDB tests")
|
|
|
|
|
|
|
|
|
|
include_directories(${LLDB_SOURCE_ROOT})
|
2017-10-04 05:20:18 +08:00
|
|
|
include_directories(${LLDB_PROJECT_ROOT}/unittests)
|
2015-03-18 06:51:21 +08:00
|
|
|
|
|
|
|
|
set(LLDB_GTEST_COMMON_INCLUDE ${CMAKE_CURRENT_SOURCE_DIR}/gtest_common.h)
|
|
|
|
|
if (MSVC)
|
|
|
|
|
list(APPEND LLVM_COMPILE_FLAGS /FI ${LLDB_GTEST_COMMON_INCLUDE})
|
|
|
|
|
else ()
|
|
|
|
|
list(APPEND LLVM_COMPILE_FLAGS -include ${LLDB_GTEST_COMMON_INCLUDE})
|
|
|
|
|
endif ()
|
|
|
|
|
|
2016-11-03 06:57:23 +08:00
|
|
|
if (LLDB_BUILT_STANDALONE)
|
|
|
|
|
# Build the gtest library needed for unittests, if we have LLVM sources
|
|
|
|
|
# handy.
|
2016-12-06 03:40:34 +08:00
|
|
|
if (EXISTS ${LLVM_MAIN_SRC_DIR}/utils/unittest AND NOT TARGET gtest)
|
2016-11-03 06:57:23 +08:00
|
|
|
add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/unittest utils/unittest)
|
|
|
|
|
endif()
|
2017-08-22 01:41:39 +08:00
|
|
|
# LLVMTestingSupport library is needed for Process/gdb-remote.
|
|
|
|
|
if (EXISTS ${LLVM_MAIN_SRC_DIR}/lib/Testing/Support
|
|
|
|
|
AND NOT TARGET LLVMTestingSupport)
|
|
|
|
|
add_subdirectory(${LLVM_MAIN_SRC_DIR}/lib/Testing/Support
|
|
|
|
|
lib/Testing/Support)
|
|
|
|
|
endif()
|
2016-11-03 06:57:23 +08:00
|
|
|
endif()
|
|
|
|
|
|
2015-03-18 06:51:21 +08:00
|
|
|
function(add_lldb_unittest test_name)
|
2017-02-02 06:17:00 +08:00
|
|
|
cmake_parse_arguments(ARG
|
|
|
|
|
""
|
|
|
|
|
""
|
|
|
|
|
"LINK_LIBS;LINK_COMPONENTS"
|
|
|
|
|
${ARGN})
|
|
|
|
|
|
|
|
|
|
list(APPEND LLVM_LINK_COMPONENTS ${ARG_LINK_COMPONENTS})
|
|
|
|
|
|
2015-03-19 00:56:24 +08:00
|
|
|
add_unittest(LLDBUnitTests
|
|
|
|
|
${test_name}
|
2017-02-02 06:17:00 +08:00
|
|
|
${ARG_UNPARSED_ARGUMENTS}
|
2015-03-19 00:56:24 +08:00
|
|
|
)
|
|
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-03 06:05:52 +08:00
|
|
|
add_custom_command(
|
|
|
|
|
TARGET ${test_name}
|
|
|
|
|
POST_BUILD
|
2018-05-10 03:58:51 +08:00
|
|
|
COMMAND "${CMAKE_COMMAND}" -E make_directory ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/Inputs)
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-03 06:05:52 +08:00
|
|
|
|
[CMake] Use PRIVATE in target_link_libraries for executables
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
2017-12-06 05:49:56 +08:00
|
|
|
target_link_libraries(${test_name} PRIVATE ${ARG_LINK_LIBS})
|
2015-03-18 06:51:21 +08:00
|
|
|
endfunction()
|
|
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-03 06:05:52 +08:00
|
|
|
function(add_unittest_inputs test_name inputs)
|
|
|
|
|
foreach (INPUT ${inputs})
|
|
|
|
|
add_custom_command(
|
|
|
|
|
TARGET ${test_name}
|
|
|
|
|
POST_BUILD
|
2018-05-10 03:58:51 +08:00
|
|
|
COMMAND "${CMAKE_COMMAND}" -E copy ${CMAKE_CURRENT_SOURCE_DIR}/Inputs/${INPUT} ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/Inputs
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-03 06:05:52 +08:00
|
|
|
COMMENT "Copying ${INPUT} to binary directory.")
|
|
|
|
|
endforeach()
|
|
|
|
|
endfunction()
|
|
|
|
|
|
2017-10-04 05:20:18 +08:00
|
|
|
add_subdirectory(TestingSupport)
|
2016-09-17 10:00:02 +08:00
|
|
|
add_subdirectory(Breakpoint)
|
2016-02-10 01:28:01 +08:00
|
|
|
add_subdirectory(Core)
|
2015-10-26 05:42:35 +08:00
|
|
|
add_subdirectory(Editline)
|
2015-11-03 03:30:40 +08:00
|
|
|
add_subdirectory(Expression)
|
2015-03-18 06:51:21 +08:00
|
|
|
add_subdirectory(Host)
|
|
|
|
|
add_subdirectory(Interpreter)
|
2016-08-18 16:21:38 +08:00
|
|
|
add_subdirectory(Language)
|
Open ELF core dumps with more than 64K sections
Summary:
Problem:
There are three filelds in the ELF header - e_phnum, e_shnum, and e_shstrndx -
that could be bigger than 64K and therefore do not fit in 16 bits reserved for
them in the header. If this happens, pretty often there is a special section at
index 0 which contains their real values for these fields in the section header
in the fields sh_info, sh_size, and sh_link respectively.
Fix:
- Rename original fields in the header declaration. We want to have them around
just in case.
- Reintroduce these fields as 32-bit members at the end of the header. By default
they are initialized from the header in Parse() method.
- In Parse(), detect the situation when the header might have been extended into
section info #0 and try to read it from the same data source.
- ObjectFileELF::GetModuleSpecifications accesses some of these fields but the
original parse uses too small data source. Re-parse the header if necessary
using bigger data source.
- ProcessElfCore::CreateInstance uses header with potentially sentinel values,
but it does not access these fields, so a comment here is enough.
Reviewers: labath
Reviewed By: labath
Subscribers: davidb, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D29095
Author: Eugene Birukov <eugenebi@hotmail.com>
llvm-svn: 293714
2017-02-01 07:09:46 +08:00
|
|
|
add_subdirectory(ObjectFile)
|
2016-09-17 10:00:02 +08:00
|
|
|
add_subdirectory(Platform)
|
2016-08-09 20:04:46 +08:00
|
|
|
add_subdirectory(Process)
|
Port native Python-API to 3.x
With this change, liblldb is 95% of the way towards being able
to work under both Python 2.x and Python 3.x. This should
introduce no functional change for Python 2.x, but for Python
3.x there are some important changes. Primarily, these are:
1) PyString doesn't exist in Python 3. Everything is a PyUnicode.
To account for this, PythonString now stores a PyBytes instead
of a PyString. In Python 2, this is equivalent to a PyUnicode,
and in Python 3, we do a conversion from PyUnicode to PyBytes
and store the PyBytes.
2) PyInt doesn't exist in Python 3. Everything is a PyLong. To
account for this, PythonInteger stores a PyLong instead of a
PyInt. In Python 2.x, this requires doing a conversion to
PyLong when creating a PythonInteger from a PyInt. In 3.x,
there is no PyInt anyway, so we can assume everything is a
PyLong.
3) PyFile_FromFile doesn't exist in Python 3. Instead there is a
PyFile_FromFd. This is not addressed in this patch because it
will require quite a large change to plumb fd's all the way
through the system into the ScriptInterpreter. This is the only
remaining piece of the puzzle to get LLDB supporting Python 3.x.
Being able to run the test suite is not addressed in this patch.
After the extension module can compile and you can enter an embedded
3.x interpreter, the test suite will be addressed in a followup.
llvm-svn: 249886
2015-10-10 03:45:41 +08:00
|
|
|
add_subdirectory(ScriptInterpreter)
|
2017-03-08 05:34:40 +08:00
|
|
|
add_subdirectory(Signals)
|
2016-04-02 07:20:35 +08:00
|
|
|
add_subdirectory(Symbol)
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-03 06:05:52 +08:00
|
|
|
add_subdirectory(SymbolFile)
|
2017-02-15 03:06:07 +08:00
|
|
|
add_subdirectory(Target)
|
New framework for lldb client-server communication tests.
Summary:
This is a new C++ test framework based on Google Test, and one working
example test.
The intention is to replace the existing tests in
packages/Python/lldbsuite/test/tools/lldb-server/ with this suite
and use this framework for all new client server tests.
Reviewers: labath, beanz
Reviewed By: labath, beanz
Subscribers: beanz, emaste, zturner, tberghammer, takuto.ikuta, krytarowski, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D32930
Patch by Jason Majors <jmajors@google.com>
llvm-svn: 304793
2017-06-06 21:40:18 +08:00
|
|
|
add_subdirectory(tools)
|
2016-09-29 09:00:16 +08:00
|
|
|
add_subdirectory(UnwindAssembly)
|
2015-03-18 06:51:21 +08:00
|
|
|
add_subdirectory(Utility)
|
2017-04-13 05:56:29 +08:00
|
|
|
|
|
|
|
|
if(LLDB_CAN_USE_DEBUGSERVER)
|
|
|
|
|
add_subdirectory(debugserver)
|
New framework for lldb client-server communication tests.
Summary:
This is a new C++ test framework based on Google Test, and one working
example test.
The intention is to replace the existing tests in
packages/Python/lldbsuite/test/tools/lldb-server/ with this suite
and use this framework for all new client server tests.
Reviewers: labath, beanz
Reviewed By: labath, beanz
Subscribers: beanz, emaste, zturner, tberghammer, takuto.ikuta, krytarowski, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D32930
Patch by Jason Majors <jmajors@google.com>
llvm-svn: 304793
2017-06-06 21:40:18 +08:00
|
|
|
endif()
|