In certain configurations, libc++ headers all exist in the same directory, and libc++ binaries exist in the same directory as lldb libs. When `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` is enabled (*and* the host is not Apple, which is why I assume this wasn't caught by others?), this is not the case: most headers will exist in the usual `include/c++/v1` directory, but `__config_site` exists in `include/$TRIPLE/c++/v1`. Likewise, the libc++.so binary exists in `lib/$TRIPLE/`, not `lib/` (where LLDB libraries reside).
This also adds the just-built-libcxx functionality to the lldb-dotest tool.
The `LIBCXX_` cmake config is borrowed from `libcxx/CMakeLists.txt`. I could not figure out a way to share the cmake config; ideally we would reuse the same config instead of copy/paste.
Reviewed By: JDevlieghere, fdeazeve
Differential Revision: https://reviews.llvm.org/D133973
This commit improves upon cc0b5ebf7f, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:
1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.
Condition (2) is new and introduced in this patch in order to support
tests that are either:
* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.
Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.
For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.
Differential Revision: https://reviews.llvm.org/D132940
This commit improves upon cc0b5ebf7f, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:
1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.
Condition (2) is new and introduced in this patch in order to support
tests that are either:
* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.
Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.
For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.
Differential Revision: https://reviews.llvm.org/D132940
MSYS 'uname' on windows returns "MSYS_NT*" instead of windows32 and also
MSYS 'pwd' returns non-windows path string.
This patch fixes Makefile.rules to make adjustments required to run LLDB
API tests using MSYS tools.
Differential Revision: https://reviews.llvm.org/D133002
This patch combines D129166 (to always pick the just-built libc++) and
D132257 (to allow customizing the libc++ for testing). The common goal
is to avoid picking up an unexpected libc++ for testing.
Differential revision: https://reviews.llvm.org/D132263
When resolving symbols during IR execution, lldb makes a last effort attempt
to resolve external symbols from object files by approximate name matching.
It currently uses `CPlusPlusNameParser` to parse the demangled function name
and arguments for the unresolved symbol and its candidates. However, this
hand-rolled C++ parser doesn’t support ABI tags which, depending on the demangler,
get demangled into `[abi:tag]`. This lack of parsing support causes lldb to never
consider a candidate mangled function name that has ABI tags.
The issue reproduces by calling an ABI-tagged template function from the
expression evaluator. This is particularly problematic with the recent
addition of ABI tags to numerous libcxx APIs.
The issue stems from the fact that `clang::CodeGen` emits function
function calls using the mangled name inferred from the `FunctionDecl`
LLDB constructs from DWARF. Debug info often lacks information for
us to construct a perfect FunctionDecl resulting in subtle mangled
name inaccuracies.
This patch side-steps the problem of inaccurate `FunctionDecl`s by
attaching an `asm()` label to each `FunctionDecl` LLDB creates from DWARF.
`clang::CodeGen` consults this label to get the mangled name as one of
the first courses of action when emitting a function call.
LLDB already does this for C++ member functions as of
[675767a591](https://reviews.llvm.org/D40283)
**Testing**
* Added API tests
Differential Revision: https://reviews.llvm.org/D131974
This commit re-applies 9ee97ce3b8, which was reverted by 61d417ce
because it broke the LLDB data formatter tests. It also re-applies
6148c79a (the manual GN change associated to it).
Differential Revision: https://reviews.llvm.org/D127444
This patch fixes LLDB API tests MakeFile.rules to allow overriding of
debug symbol flags when compiling tests for Windows.
Previously windows tests were forced to emit only dwarf debug symbols
as majority of the tests rely on dwarf debug info. After this patch
any test can override debug symbol flag by setting DEBUG_INFO_FLAG
variable in its make file.
This patch removes use of -fno-builtin flag for building LLDB API
tests.
LLDB API tests are built using Makefile.rules where we were using
-fno-builtin flag to avoid gcc intrinsic optimization conflicting
with Android runtime in past.
Now that we no longer use gcc for building testsuite and compiling
LLDB API tests on AArch64/Windows require clang to optimize certain
calls like _setjmp to setjmpex as former is not implemented by
AArch64 windows runtime.
This patch fixes an issue, where if the thread has a signal blocked when
we try to inject it into the process (via vCont), then instead of
executing straight away, the injected signal will trigger another stop
when the thread unblocks the signal.
As (linux) threads start their life with SIGUSR1 (among others)
disabled, and only enable it during initialization, injecting the signal
during this window did not behave as expected. The fix is to change the
test to ensure the signal gets injected with the signal unblocked.
The simplest way to do this was to write a dedicated inferior for this
test. I also created a new header to factor out the function retrieving
the (os-specific) thread id.
On my Debian machine, system libc++/libc++abi is not installed (`libc++1-9 libc++abi-9`),
21 check-lldb-api tests fail because -stdlib=libc++ linked executables cannot
find runtime libc++.so.1 at runtime.
Use the `-Wl,-rpath,$(LLVM_LIBS_DIR)` mechanism in
`packages/Python/lldbsuite/test/make/Makefile.rules` (D58630 for NetBSD) to
allow such tests compile/link with fresh libc++ built beside lldb.
(A system libc++.so.1 is not guaranteed to match fresh libc++ header files.)
Some tweaks to the existing NetBSD rule when generalizing:
* Drop `-L$(LLVM_LIBS_DIR)` since Clang driver adds it correctly.
* Add `-stdlib=libc++` only for `USE_LIBCPP`.
Also, drop `-isystem /usr/include/c++/v1` introduced in D9426. It is not needed
by Clang driver. GCC using libc++ requires more setup.
I don't find any test needing `-Wl,-rpath` in `test/Shell/helper/{build,toolchain}.py` (D58630 for NetBSD added them).
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D94888
It seems that if codesigning the test executables with the
`com.apple.private.security.no-sandbox` entitlement then the simulator refuses
to launch them and every test fails with `Process launch failed: process exited
with status -1 (no such process.)`.
This patch checks if we're trying to run the test suite on the simulator and
then avoids signing the executable with `no-sandbox`.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89052
Rather than have different modules for different platforms, use
inheritance so we can have a Builer base class and optional child
classes that override platform specific methods.
Differential revision: https://reviews.llvm.org/D86174
The sed line in the rules was adding the .d file as a target to the
dependency rules -- to ensure the file gets rebuild when the sources
change. The same thing can be achieved more elegantly with some -M
flags.
It's possible to achieve the same effect by providing multi-step recipe
instead of a single-step recipe where the step happens to contain
multiple commands.
and delete a bunch (but not all) redundant code. If you compare the remaining implementations of Platform*Simulator.cpp, there is still an obvious leftover cleanup task.
Specifically, this patch
- removes SDK initialization from dotest (there is equivalent but more
complete code in Makefile.rules)
- make Platform*Simulator inherit the generic implementation of
PlatformAppleSimulator (more can be done here)
- simplify the platform logic in Makefile.rules
- replace the custom SDK finding logic in Platform*Simulator with XcodeSDK
- adds a test for each supported simulator
Differential Revision: https://reviews.llvm.org/D81980
This makes it possible to conditionally override some of these flags via
CFLAGS_EXTRAS. It should be NFC right now, but this seems the logical
order in which to apply these things, and I am going to make use of this
in another patch.
This reverts commit fd0ab3b3eb.
The fix here is incorrect and the actual fault was an incorrect test Makefile.
To give some more background:
The original test for D80798 compiled three source files into either one
executable or one executable + 2 shared libraries, each being one different
test setup. If both the monolithic executable and the shared libraries
where compiled in the same directory, then Make would overwrite the .o files
of one test setup with the other. This caused that while -fPIC was passed
correctly to the test setup with the shared libraries, the compiler invocations
for the monolithic executable would later overwrite these object files (and
as only the test setup with the shared library used -fPIC, it appeared as if
the shared library object files didn't receive the -fPIC flag).
Thanks to Pavel for figuring this out.
Summary:
It seems that when we rewrite a few rules to only build a dylib (i.e., when DYLIB_ONLY is set),
the rule for setting the CFLAGS for the dylib's object file compilation will no longer work. From what I can
see this is because in DYLIB_ONLY mode we pretend to compile the main executable so
the DYLIB_OBJECTS scope is actually never used.
This patch makes `-fPIC` unstopped if DYLIB_ONLY is set so that -fPIC actually ends up in the
CFLAGS for the dylib object file compilation.
The test for this is D80798 which only compiles on Linux with this patch.
Reviewers: friss, labath
Reviewed By: friss
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D80789
Summary:
This patch introduces a header "dylib.h" which can be used in tests to
handle shared libraries semi-portably. The shared library APIs on
windows and posix systems look very different, but their underlying
functionality is relatively similar, so the mapping is not difficult.
It also introduces two new macros to wrap the functinality necessary to
export/import function across the dll boundary on windows. Previously we
had the LLDB_TEST_API macro for this purpose, which automagically
changed meaning depending on whether we were building the shared library
or the executable. While convenient for simple cases, this approach was
not sufficient for the more complicated setups where one deals with
multiple shared libraries.
Lastly it rewrites TestLoadUnload, to make use of the new APIs. The
trickiest aspect there is the handling of DYLD_LIBRARY_PATH on macos --
previously setting this variable was not needed as the test used
@executable_path-relative dlopens, but the new generic api does not
support that. Other systems do not support such dlopens either so the
test already contained support for setting the appropriate path
variable, and this patch just makes that logic more generic. In doesn't
seem that the purpose of this test was to exercise @executable_path
imports, so this should not be a problem.
These changes are sufficient to make some of the TestLoadUnload tests
pass on windows. Two other tests will start to pass once D77287 lands.
Reviewers: amccarth, jingham, JDevlieghere, compnerd
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77662
The test harness invokes the test Makefiles with an explicit 'all'
target, but it's handy to be able to recursively call Makefile.rules
without speficying a goal.
Some time ago, we rewrote some tests in terms of recursive invocations
of Makefile.rules. It turns out this had an unintended side
effect. While using $(MAKE) for a recursive invocation passes all the
variables set on the command line down, it doesn't pass the make
goals. This means that those recursive invocations would invoke the
default rule. It turns out the default rule of Makefile.rules is not
'all', but $(EXE). This means that ti would work becuase the
executable is always needed, but it also means that the created
binaries would not follow some of the other top-level build
directives, like MAKE_DSYM.
Forcing 'all' to be the default target seems easier than making sure
all the invocations are correct going forward. This patch does this
using the .DEFAULT_GOAL directive rather than hoisting the 'all' rule
to be the first one of the file. It seems like this explicit approach
will be less prone to be broken in the future. Hopefully all the make
implementations we use support it.
This feature is mostly there to aid debugging of Clang module issues,
since the only useful actual the end-user can to is to recompile their
program.
Differential Revision: https://reviews.llvm.org/D70272
This patch fixes whitespace/tabs mismatch in
lldb/packages/Python/lldbsuite/test/make/Makefile.rules
Legacy make files always used tabs though modern make version can
work with white-spaces I have chosen the legacy just to be safe.
Signed-off-by: Muhammad Omair Javaid <omair.javaid@linaro.org>
Differential Revision: https://reviews.llvm.org/D70154
This patch adds core definitions in lldb ArchSpecs for armv8l and armv7l cores.
This was needed because on Linux running on 32-bit Arm v8 we are returned
armv8l in case we are running 32-bit sysroot on 64bit kernel. In case of 32-bit
kernel and 32-bit sysroot running on arm v8 hardware we are returned armv7l.
This is quite common when we run 32 bit arm using docker container.
Signed-off-by: Muhammad Omair Javaid <omair.javaid@linaro.org>
Differential Revision: https://reviews.llvm.org/D69904
Auto-detecting CC in Makefile.rules is no longer useful. Ever since
out-of-tree builds we are better off just running lldb-dotest which
sets it directly. This also makes it harder to accidentally unset CC
in a Makefile.
Differential Revision: https://reviews.llvm.org/D68731
llvm-svn: 374402
Before the test reorganization, everything was part of a single test
suite with a single module cache. Now that things are properly separated
this is no longer the case. Only the shell tests inherited the logic to
properly configure and wipe the module caches. This patch adds that
logic back for the API tests. While doing so, I noticed that we were
configuring a Clang module cache in CMake, but weren't actually using it
from dotest.py. I included a fix for that in this patch as well.
Differential revision: https://reviews.llvm.org/D68755
llvm-svn: 374386
When building an executable and a shared library at the same time (yes,
Makefile.rules is setup to do this!) the executable was not codesigned.
llvm-svn: 374251
Most of the secondary Makefiles we have are just a couple variable
definitions and then an include of Makefile.rules. This patch removes
most of the secondary Makefiles and replaces them with a direct
invocation of Makefile.rules in the main Makefile. The specificities
of each sub-build are listed right there on the recursive $(MAKE)
call. All the variables that matter are being passed automagically by
make as they have been passed on the command line. The only things you
need to specify are the variables customizating the Makefile.rules
logic for each image.
This patch also removes most of the clean logic from those Makefiles
and from Makefile.rules. The clean rule is not required anymore now
that we run the testsuite in a separate build directory that is wiped
with each run. The patch leaves a very crude version of clean in
Makefile.rules which removes everything inside of $(BUILDDIR). It does
this only when the $(BUILDDIR) looks like a sub-directory of our
standard testsuite build directory to be extra safe.
Reviewers: aprantl, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68558
llvm-svn: 374076
This test streamlines our use of variables that are expected by
Makefile.rules throughout the test suite. Mostly it replaced
potentially dangerous overrides and updates of variables like CFLAGS
with safe assignments to variables reserved for this purpose like
CFLAGS_EXTRAS.
Differential Revision: https://reviews.llvm.org/D67984
llvm-svn: 372795
This patch extends the Makefile.rules to build NeXT-style frameworks. It
also fixes a bug in the clean logic that would accidentally delete the
.mm source file instead of the .o object file.
Thanks a lot to Adrian who was instrumental is getting this to work!
llvm-svn: 372669
This reverts my change to pseudo_barrier.h which isn't necessary anymore
after Fred's fix to debugserver and caused TestThreadStepOut to fail.
llvm-svn: 370963
plugin.
Unfortunately the test is currently XFAILed because of missing changes
to the clang driver.
Differential Revision: https://reviews.llvm.org/D67124
llvm-svn: 370931
The flakiness on our local machines seems to come for a race in the kernel
between task_suspend and the creation of the Mach exceptions for the threads
that hit breakpoints. The debugserver code is written with the assumption
that the kernel will be able to provide us with all the exceptions for a
given task once task_suspend returns. On machines with higher core counts,
this seems not to be the case. The first batch of exceptions we get after
task_suspend does not contain exceptions for all the threads that have hit
a breakpoint, thus they get misreprorted in the first stop packet.
Adding a 1ms timeout to the call that retrieves the batch of exceptions
seems to workaround the issue reliably on our machines, and it shoulnd't
impact standard debugging scenarios too much (a stop will incur an additional
1ms delay). We'll be talking to the kernel team to figure out the right
contract for those APIs.
This patch also reverts part of Jonas' previous workaround for the
issue (r370785).
llvm-svn: 370916
On "fast" macOS machines, the TestConcurrentMany*.py tests would fail
randomly with different numbers of breakpoints, watchpoints, etc. This
seems to be avoidable by giving the threads a little time to breath
after the passing the synchronization barrier. This is far from a
structural fix but it reduces the flakiness.
llvm-svn: 370785
Summary:
Fixed `Android.rules` for running test suite on remote android
- the build configuration is not compatible with ndk structure, change it to link to static libc++
- generally clang should be able to use libc++ and will link against the right library, but some libc++ installations require the user manually link libc++abi.
- add flag `-lc++abi` to fix the test binary build failure
Added `skipIfTargetAndroid` `skipUnlessTargetAndroid` for better test support
- the `skipIfPlatform` method will ask `lldbplatformutil.getPlatform()` for platform info which is actually the os type, and //Android// is not os type but environment
- create this function to handle the android target condition
**To Run Test on Remote Android**
1 start lldb-server on your devices
2 run lldb-dotest with following configuration:
`./lldb-dotest --out-of-tree-debugserver --arch aarch64 --platform-name remote-android --platform-url connect://localhost:12345 --platform-working-dir /data/local/tmp/ --compiler your/ndk/clang`
Reviewers: xiaobai, labath
Reviewed By: labath
Subscribers: labath, javed.absar, kristof.beyls, srhines, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64118
llvm-svn: 365561
Jordan Rupprecht