When gathering the headers to fix up and place in LLDB.framework, we
were previously globbing the header files from a location in the build
directory. This commit changes this to glob from the source directory
instead, as we were globbing from the build directory without ensuring
that the necessary files were actually in that location before globbing.
There's 2 bugs that this commit fixes:
1. Calculate the correct file path for the output file by appending the
basename of the input header instead of appending the entire input
header's path to the framework path.
2. In the script, create the framework's header directory if it does not
exist.
The script used to fix up LLDB's header for use in the macOS framework
contained 2 bugs that this commit addreses:
1. The output contents were appended to the output file multiple times
instead of only being written once.
2. The script was not considering LLDB includes that were *not* from the
SB API.
This commit addresses and fixes both of these bugs and updates the
corresponding test to match.
In the script that's used by RPC to convert LLDB headers to LLDB RPC
headers, there's a bug with how it converts namespace usage. An
overeager regex pattern caused *all* text before any `lldb::` namespace
usage to get replaced with `lldb_rpc::` instead of just the namespace
itself. This commit changes that regex pattern to be less overeager and
modifies one of the shell tests for this script to actually check that
the namespace usage replacement is working correctly.
rdar://154126268
…ers" (#143941)
Reland the script that converts lldb headers to RPC headers. The RPC
test was failing due to the incorrect input filepath being used.
Original commit message:
This commit replaces the shell script that fixes up includes for the
LLDB framework with a Python script. This script will also be used when
fixing up includes for the LLDBRPC.framework.
This commit replaces the shell script that fixes up includes for the
LLDB framework with a Python script. This script will also be used when
fixing up includes for the LLDBRPC.framework.
This relands the original commit for the versioning script in LLDB. This
commit uses '>' for output from `unifdef` for platforms that have that
executable but do not have the `-o` option. It also fixes the Xcode
build by adding a dependency between the liblldb-header-staging target
in the source/API/CMakeLists.txt the `liblldb-resource-headers` target
in LLDBFramework.cmake.
Original patch: https://github.com/llvm/llvm-project/pull/141116
This commit creates a Python script that fixes up the versioning
information in lldb-defines.h. It also moves the build logic for fixing
up the lldb headers from being in the framework only to being in the
same location that we create the liblldb target.
SBLanguages.h uses a uint16_t but is missing the include for
`<cstdint>`, if any file includes this without including that it will
cause a build error so this commit adds this include.
LLDB_EXPORT_ALL_SYMBOLS is useful when building out-of-tree plugins and
extensions that rely on LLDB's internal symbols. For example, this is
how the Mojo language provides its REPL and debugger support.
Supporting this on windows is kind of tricky because this is normally
expected to be done using dllexport/dllimport, but lldb uses these with
the public api. This PR takes an approach similar to what LLVM does with
LLVM_EXPORT_SYMBOLS_FOR_PLUGINS, and what chromium does for
[abseil](253d14e20f/third_party/abseil-cpp/generate_def_files.py),
and uses a python script to extract the necessary symbols by looking at
the symbol table for the various lldb libraries.
These were useful primarily for the Python 2 to 3 transition. Python 2
is no longer supported so these are no longer necessary.
Differential Revision: https://reviews.llvm.org/D157759
Allow users to use a non-system version of perl, python and awk, which is useful
in certain package managers.
Reviewed By: JDevlieghere, MaskRay
Differential Revision: https://reviews.llvm.org/D95119
This extends the "memory region" command to
show tagged regions on AArch64 Linux when the MTE
extension is enabled.
(lldb) memory region the_page
[0x0000fffff7ff8000-0x0000fffff7ff9000) rw-
memory tagging: enabled
This is done by adding an optional "flags" field to
the qMemoryRegion packet. The only supported flag is
"mt" but this can be extended.
This "mt" flag is read from /proc/{pid}/smaps on Linux,
other platforms will leave out the "flags" field.
Where this "mt" flag is received "memory region" will
show that it is enabled. If it is not or the target
doesn't support memory tagging, the line is not shown.
(since majority of the time tagging will not be enabled)
Testing is added for the existing /proc/{pid}/maps
parsing and the new smaps parsing.
Minidump parsing has been updated where needed,
though it only uses maps not smaps.
Target specific tests can be run with QEMU and I have
added MTE flags to the existing helper scripts.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D87442
This patch adds a HowTo document to lldb docs which gives instruction for
setting up a virtual environment based on QEMU emulator for LLDB testing.
Instruction in this document are tested on Arm and AArch64 targets but
can easily be duplicated for other targets supported by QEMU.
This helps test LLDB in absence for modern AArch64 features not released
in publicly available hardware till date.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D82064
Several scripts (two copies of use_lldb_suite.py, and an __init__.py) look for use_lldb_suite_root.py by checking parent directories. If for some reason it doesn't exist, it keeps checking parent directories until it finds it.
However, this only breaks when the parent directory is None, but at least on Linux, dirname('/') == '/', so this will never be None.
This changes the lookup to stop if the dirname(lldb_root) is unchanged. This was previously fixed in 67f6d842fab6d3ac8c949721be8e131cf6b17578, but only in one copy of this script.
Additionally, this makes the failure mode more visible -- if the root is not found, it complains loudly instead of silently failing, and having later modules that need lldb_root fail.
Differential Revision: https://reviews.llvm.org/D83840
Add two modes to the reproducer replay script that make debugging a
little easier. Verbose mode prints stdout and stderr, regardless of
whether replay was successful. When --failure-only is passed, output is
limited to tests that failed to replay.
All the code required to generate the language bindings for Python and
Lua lives under scripts, even though the majority of this code aren't
scripts at all, and surrounded by scripts that are totally unrelated.
I've reorganized these files and moved everything related to the
language bindings into a new top-level directory named bindings. This
makes the corresponding files self contained and much more discoverable.
Differential revision: https://reviews.llvm.org/D72437
Making the string conversion operator a macro unintentionally dropped
the backslash before '\n' and '\r' and was therefore incorrectly
stripping 'n' and 'r' from the object description.
The current SWIG extensions for the string conversion operator is Python
specific because it uses the PythonObjects. This means that the code
cannot be reused for other SWIG supported languages such as Lua.
This reimplements the extensions in a more generic way that can be
reused. It uses a SWIG macro to reduce code duplication.
Differential revision: https://reviews.llvm.org/D72377
The current SWIG extensions for the string conversion operator is Python
specific because it uses the PythonObjects. This means that the code
cannot be reused for other SWIG supported languages such as Lua.
This reimplements the extensions in a more generic way that can be
reused. It uses a SWIG macro to reduce code duplication.
Differential revision: https://reviews.llvm.org/D72377
The current SWIG extensions for the string conversion operator is Python
specific because it uses the PythonObjects. This means that the code
cannot be reused for other SWIG supported languages such as Lua.
This reimplements the extensions in a more generic way that can be
reused.
Differential revision: https://reviews.llvm.org/D72377
As correctly pointed out by Martin on the mailing list, Python should
only be auto-enabled if SWIG is found as well. This moves the logic of
finding SWIG into FindPythonInterpAndLibs to make that possible.
To make diagnosing easier I've included a status message to convey why
Python support is disabled.
