Refactoring `stackTrace` to perform frame look ups in a more on-demand
fashion to improve overall performance.
Additionally adding additional information to the `exceptionInfo`
request to report exception stacks there instead of merging the
exception stack into the stack trace. The `exceptionInfo` request is
only called if a stop event occurs with `reason='exception'`, which
should mitigate the performance of `SBThread::GetCurrentException`
calls.
Adding unit tests for exception handling and stack trace supporting.
This causes a number of tests be `UNRESOLVED` on Windows if
`getCompiler()` has a space in the name, because `getCompilerBinary()`
unconditionally splits on whitespace and returns the first result, which
might just be`"C:\Program"` if using a compiler such as `clang-cl` `cl`
from the absolute path to Visual studio's installation directory.
Co-authored-by: kendal <kendal@thebrowser.company>
## Issue
Attempting to run the lldb API tests against a remote-android target
fails with the error `NameError: name 'urlparse' is not defined`.
## Root Cause
It looks the Python import of `urlparse` was removed by mistake in
22ea97d7bfd65abf68a68b13bf96ad69be23df54. This import is only used when
running the lldb API tests against a remote-android target so it went
unnoticed.
## Fix
This change simply puts back the missing import. It is a one line
change.
fixes#99931
## Validation
Tested on Fedora 39 with an attached Android device:
`cd llvm-project`
`cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS='clang;lldb'
-DCMAKE_BUILD_TYPE=Release -DLLDB_ENABLE_PYTHON=On`
`ninja -C build`
`./build/bin/lldb-dotest --arch aarch64 --out-of-tree-debugserver
--platform-name=remote-android
--platform-working-dir=/data/local/tmp/ds2
--platform-url=connect://localhost:5432 --compiler
~/Android/Sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/clang`
Makefile.rules uses HOST_OS and OS variables for determining host and target
OSes for API tests compilation.
This commit moves the platform detection logic from Makefile to Python lldb
test suite.
This is useful for the case of Windows-to-Linux cross-testing.
Use the packaging [1] module for parsing version numbers, instead of
pkg_resources which is distributed with setuptools. I recently switched
over to using the latter, knowing it was deprecated (in favor of the
packaging module) because it comes with Python out of the box. Newer
versions of setuptools have removed `pkg_resources` so we have to use
packaging.
[1] https://pypi.org/project/packaging/
When Apple released its new linker, it had a subtle bug that caused
LLDB's TLS tests to fail. Unfortunately this means that TLS tests are
not going to work on machines that have affected versions of the linker,
so we should annotate the tests so that they only work when we are
confident the linker has the required fix.
I'm not completely satisfied with this implementation. That being said,
I believe that adding suport for linker versions in general is a
non-trivial change that would require far more thought. There are a few
challenges involved:
- LLDB's testing infra takes an argument to change the compiler, but
there's no way to switch out the linker.
- There's no standard way to ask a compiler what linker it will use.
- There's no standard way to ask a linker what its version is. Many
platforms have the same name for their linker (ld).
- Some platforms automatically switch out the linker underneath you. We
do this for Windows tests (where we use LLD no matter what).
Given that this is affecting the tests on our CI, I think this is an
acceptable solution in the interim.
The distutils package has been deprecated and was removed from Python
3.12. The migration page [1] advises to use the packaging module
instead. Since Python 3.6 that's vendored into pkg_resources.
[1] https://peps.python.org/pep-0632/#migration-advice
The distutils package has been deprecated and was removed from Python
3.12. The migration page [1] advises to use the packaging module
instead. Since Python 3.6 that's vendored into pkg_resources.
[1] https://peps.python.org/pep-0632/#migration-advice
This is partial step toward removing the vendored `unittest2` dep in
favor of the `unittest` library in standard python. One of the large
differences is when xfail decorators are evaluated. With the `unittest2`
vendored dep, this can happen at the moment of calling the test case,
and with LLDB's decorator wrappers, we are passed the test class in the
decorator arg. With the `unittest` framework, this is determined much
earlier; we cannot decide when the test is about to start that we need
to xfail.
Fortunately, almost none of these checks require any state that can't be
determined statically. For this patch, I moved the impl for all the
checks to `lldbplatformutil` and pointed the decorators to that,
removing as many `self` (i.e. test class object) references as possible.
I left wrappers within `TestBase` that forward to `lldbplatformutil` for
convenience, but we should probably remove those later.
The remaining check that can't be moved statically is the check for the
debug info type (e.g. to xfail only for dwarf). Fixing that requires a
different approach, so I will postpone that to the next patch.
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
This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).
If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.
RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Differential revision: https://reviews.llvm.org/D151460
Previously, we just used the platform name. This worked mostly OK, but
it required adding special handling for any unusual (and potentially
downstream) platform plugins, as evidenced by the hardcoding of the
qemu-user platform.
The current implementation was added in
D121605/21c5bb0a636c23ec75b13681c0a6fdb03ecd9c0d, which this essentially
reverts and goes back to the previous method of retrieving the platform
name from the platform triple (the "OS" field).
The motivation for D121605 was the ability to retrieve the process
without constructing an SBDebugger object (which would be necessary in a
world where SBPlatforms are managed by SBDebuggers). However, this world
did not arrive (mainly due to other commitments on my part), and I now
think that if we do want to go in that direction, that we should just
create a dummy/empty SBDebugger object for holding the initial
SBPlatform.
One benefit of D121605 was the unification of getPlatform and
getHostPlatform code paths, and I preserve that benefit by unifying them
in the other direction -- using the host SBPlatform for getHostPlatform.
Differential Revision: https://reviews.llvm.org/D138430
This recommits b15b1421, which reverted in was reverted in f51c47d98 due to
failures on apple systems. The problem was that the patch introduced a race
where the debug server could start the attach process before the first process
(which isn't supposed to be attached to) was set up. This caused us to attach
to the wrong process.
The new version introduces additional synchronization to ensure that does not
happen.
Original commit message was:
As the documentation states, using this is not safe in multithreaded
programs, and I have traced it to a rare deadlock in some of the tests.
The reason this was introduced was to be able to attach to a program
from the very first instruction, where our usual mechanism of
synchronization -- waiting for a file to appear -- does not work.
However, this is only needed for a single test
(TestGdbRemoteAttachWait) so instead of doing this everywhere, I create
a bespoke solution for that single test. The solution basically
consists of outsourcing the preexec_fn code to a separate (and
single-threaded) shim process, which enables attaching and then executes
the real program.
This pattern could be generalized in case we needed to use it for other
tests, but I suspect that we will not be having many tests like this.
This effectively reverts commit
a997a1d7fbe229433fb458bb0035b32424ecf3bd.
As the documentation states, using this is not safe in multithreaded
programs, and I have traced it to a rare deadlock in some of the tests.
The reason this was introduced was to be able to attach to a program
from the very first instruction, where our usual mechanism of
synchronization -- waiting for a file to appear -- does not work.
However, this is only needed for a single test
(TestGdbRemoteAttachWait) so instead of doing this everywhere, I create
a bespoke solution for that single test. The solution basically
consists of outsourcing the preexec_fn code to a separate (and
single-threaded) shim process, which enables attaching and then executes
the real program.
This pattern could be generalized in case we needed to use it for other
tests, but I suspect that we will not be having many tests like this.
This effectively reverts commit
a997a1d7fbe229433fb458bb0035b32424ecf3bd.
This recommits dddf4ce03, which was reverted because of a couple of test
failures on macos. The reason behind the failures was that the patch
inadvertenly changed the value returned by the host platform from
"macosx" to "darwin". The new version fixes that.
Original commit message was:
The decision which categories are relevant for a particular test run
happen very early in the test setup process. They use the SBPlatform
object to determine which categories should be skipped. The platform
object created for this purpose transcends individual test runs.
This setup is not compatible with the direction discussed in
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>
-- when platform objects are tied to a specific (SB)Debugger, they need
to be created alongside it, which currently happens in the test setUp
method.
This patch is the first step in that direction -- it rewrites the
category skipping logic to avoid depending on a global SBPlatform
object. Fortunately, the skipping logic is fairly simple (and I believe
it outght to stay that way) and mainly consists of comparing the
platform name against some hardcoded lists. This patch bases this
comparison on the platform name instead of the os part of the triple (as
reported by the platform).
Differential Revision: https://reviews.llvm.org/D121605
The decision which categories are relevant for a particular test run
happen very early in the test setup process. They use the SBPlatform
object to determine which categories should be skipped. The platform
object created for this purpose transcends individual test runs.
This setup is not compatible with the direction discussed in
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>
-- when platform objects are tied to a specific (SB)Debugger, they need
to be created alongside it, which currently happens in the test setUp
method.
This patch is the first step in that direction -- it rewrites the
category skipping logic to avoid depending on a global SBPlatform
object. Fortunately, the skipping logic is fairly simple (and I believe
it outght to stay that way) and mainly consists of comparing the
platform name against some hardcoded lists. This patch bases this
comparison on the platform name instead of the os part of the triple (as
reported by the platform).
Differential Revision: https://reviews.llvm.org/D121605
Linux systems can be configured (and most of them are configured that
way) to disable attaching to unrelated processes, /unless/ those
processes explicitly allow that.
Our test inferiors do that by explicitly calling prctl(PR_SET_PTRACER,
PR_SET_PTRACER_ANY) (a.k.a., lldb_enable_attach). This requires
additional synchronization to ensure that the test does not attempt
attach before that statement is executed.
This is working fine (albeit cumbersome) for most tests but
TestGdbRemoteAttachWait is special in that it wants to start the
inferior _after_ issuing the attach request. This means that the usual
synchronization method does not work.
This patch introduces a different solution -- enable attaching in the
test harness, before the process is launched. Besides fixing this
problem, this is also better because it avoids the need to add special
code to each attach test (which is a common error).
One gotcha here is that it won't work for remote test suites, as we
don't control launching there. However, we could add a similar option to
lldb-platform, or require that lldb-platform itself is started with
attaching enabled. At that point we could delete all lldb_enable_attach
logic.
This just adds the simulator platforms to the lldbplatform enumerations
and the respective test decorator.
The platform names for the simulator are just the SDK names since D85537, so
that's why we are not using LLDB's usual platform names here (e.g., SDK =
"iphonesimulator" vs LLDB platform ="ios-simulator").
Also removes the duplicate platform enumaration in lldbplatformutil.py.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89694
This patch stores the --apple-sdk argument in the dotest configuration.
When it's set, use it instead of the triple to determine the current
platform.
Differential revision: https://reviews.llvm.org/D85537
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
Some tests set settings and don't clean them up, this leads to side effects in other tests.
The patch removes a global debugger instance with a per-test debugger to avoid such effects.
From what I see, lldb.DBG was needed to determine the platform before a test is run,
lldb.selected_platform is used for this purpose now. Though, this required adding a new function
to the SBPlatform interface.
Differential Revision: https://reviews.llvm.org/D74903
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
New android ndk linker started adding more flags to the produced
binaries, which causes older dynamic linkers display warnings to stderr
about unsupported flags. This interferes with our stderr tests.
Extend the hasChattyStderr function to catch these targets as well.
llvm-svn: 319028
Normal customer devices won't be able to run these tests, we're hoping to get
a public facing bot set up at some point. Both devices pass the testsuite without
any errors or failures.
I have seen some instability with the armv7 test runs, I may submit additional patches
to address this. arm64 looks good.
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 314132
Normal customer devices won't be able to run these devices, we're hoping to get
a public facing bot set up at some point. Both devices pass the testsuite without
any errors or failures.
I have seen some instability with the armv7 test runs, I may submit additional patches
to address this. arm64 looks good.
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 314038
Normal customer devices won't be able to run these devices, we're hoping to get
a public facing bot set up at some point.
There will be some smaller follow-on patches. The changes to tools/lldb-server are
verbose and I'm not thrilled with having to skip all of these tests manually.
There are a few places where I'm making the assumption that "armv7", "armv7k", "arm64"
means it's an ios device, and I need to review & clean these up with an OS check
as well. (Android will show up as "arm" and "aarch64" so by pure luck they shouldn't
cause problems, but it's not an assumption I want to rely on).
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 313932
This adds a simple testcase for MainThreadCheckerRuntime. The tool (Main Thread Checker) is only available on Darwin, so the test also detects the presence of libMainThreadChecker.dylib and is skipped if the tool is not available.
llvm-svn: 307170
Summary:
This aims to replace the different decorators we've had on each libc++
test with a single solution. Each libc++ will be assigned to the
"libc++" category and a single central piece of code will decide whether
we are actually able to run libc++ test in the given configuration by
enabling or disabling the category (while giving the user the
opportunity to override this).
I started this effort because I wanted to get libc++ tests running on
android, and none of the existing decorators worked for this use case:
- skipIfGcc - incorrect, we can build libc++ executables on android
with gcc (in fact, after this, we can now do it on linux as well)
- lldbutil.skip_if_library_missing - this checks whether libc++.so is
loaded in the proces, which fails in case of a statically linked
libc++ (this makes copying executables to the remote target easier to
manage).
To make this work I needed to split out the pseudo_barrier code from the
force-included file, as libc++'s atomic does not play well with gcc on
linux, and this made every test fail, even though we need the code only
in the threading tests.
So far, I am only annotating one of the tests with this category. If
this does not break anything, I'll proceed to update the rest.
Reviewers: jingham, zturner, EricWF
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D30984
llvm-svn: 299028
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
Summary:
On some android targets, a binary can produce additional garbage (e.g. warning messages from the
dynamic linker) on the standard error, which confuses some tests. This relaxes the stderr
expectations for targets known for their chattyness.
Reviewers: tfiala, ovyalov
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D19114
llvm-svn: 266326
This patch adds support for Linux on SystemZ:
- A new ArchSpec value of eCore_s390x_generic
- A new directory Plugins/ABI/SysV-s390x providing an ABI implementation
- Register context support
- Native Linux support including watchpoint support
- ELF core file support
- Misc. support throughout the code base (e.g. breakpoint opcodes)
- Test case updates to support the platform
This should provide complete support for debugging the SystemZ platform.
Not yet supported are optional features like transaction support (zEC12)
or SIMD vector support (z13).
There is no instruction emulation, since our ABI requires that all code
provide correct DWARF CFI at all PC locations in .eh_frame to support
unwinding (i.e. -fasynchronous-unwind-tables is on by default).
The implementation follows existing platforms in a mostly straightforward
manner. A couple of things that are different:
- We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers,
since some registers (access register) reside at offsets in the user area
that are multiples of 4, but the PTRACE_PEEKUSER interface only allows
accessing aligned 8-byte blocks in the user area. Instead, we use a s390
specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that
allows accessing a whole block of the user area in one go, so in effect
allowing to treat parts of the user area as register sets.
- SystemZ hardware does not provide any means to implement read watchpoints,
only write watchpoints. In fact, we can only support a *single* write
watchpoint (but this can span a range of arbitrary size). In LLDB this
means we support only a single watchpoint. I've set all test cases that
require read watchpoints (or multiple watchpoints) to expected failure
on the platform. [ Note that there were two test cases that install
a read/write watchpoint even though they nowhere rely on the "read"
property. I've changed those to simply use plain write watchpoints. ]
Differential Revision: http://reviews.llvm.org/D18978
llvm-svn: 266308
This doesn't attempt to move every decorator. The reason for
this is that it requires touching every single test file to import
decorators.py. I would like to do this in a followup patch, but
in the interest of keeping the patches as bite-sized as possible,
I've only attempted to move the underlying common decorators first.
A few tests call these directly, so those tests are updated as part
of this patch.
llvm-svn: 259807
