| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
The original patch got reverted because it broke `check-lldb` on a clean
build. This fixes that.
llvm-svn: 374201
|
| |
|
|
|
|
|
|
| |
as it appears to have broken check-lldb.
This reverts r374184 (git commit 22314179f0660c172514b397060fd8f34b586e82)
llvm-svn: 374187
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLDB has three major testing strategies: unit tests, tests that exercise
the SB API though dotest.py and what we currently call lit tests. The
later is rather confusing as we're now using lit as the driver for all
three types of tests. As most of this grew organically, the directory
structure in the LLDB repository doesn't really make this clear.
The 'lit' tests are part of the root and among these tests there's a
Unit and Suite folder for the unit and dotest-tests. This layout makes
it impossible to run just the lit tests.
This patch changes the directory layout to match the 3 testing
strategies, each with their own directory and their own configuration
file. This means there are now 3 directories under lit with 3
corresponding targets:
- API (check-lldb-api): Test exercising the SB API.
- Shell (check-lldb-shell): Test exercising command line utilities.
- Unit (check-lldb-unit): Unit tests.
Finally, there's still the `check-lldb` target that runs all three test
suites.
Finally, this also renames the lit folder to `test` to match the LLVM
repository layout.
Differential revision: https://reviews.llvm.org/D68606
llvm-svn: 374184
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If the .symtab section is stripped from the binary it might be that
there's a .gnu_debugdata section which contains a smaller .symtab in
order to provide enough information to create a backtrace with function
names or to set and hit a breakpoint on a function name.
This change looks for a .gnu_debugdata section in the ELF object file.
The .gnu_debugdata section contains a xz-compressed ELF file with a
.symtab section inside. Symbols from that compressed .symtab section
are merged with the main object file's .dynsym symbols (if any).
In addition we always load the .dynsym even if there's a .symtab
section.
For example, the Fedora and RHEL operating systems strip their binaries
but keep a .gnu_debugdata section. While gdb already can read this
section, LLDB until this patch couldn't. To test this patch on a
Fedora or RHEL operating system, try to set a breakpoint on the "help"
symbol in the "zip" binary. Before this patch, only GDB can set this
breakpoint; now LLDB also can do so without installing extra debug
symbols:
lldb /usr/bin/zip -b -o "b help" -o "r" -o "bt" -- -h
The above line runs LLDB in batch mode and on the "/usr/bin/zip -h"
target:
(lldb) target create "/usr/bin/zip"
Current executable set to '/usr/bin/zip' (x86_64).
(lldb) settings set -- target.run-args "-h"
Before the program starts, we set a breakpoint on the "help" symbol:
(lldb) b help
Breakpoint 1: where = zip`help, address = 0x00000000004093b0
Once the program is run and has hit the breakpoint we ask for a
backtrace:
(lldb) r
Process 10073 stopped
* thread #1, name = 'zip', stop reason = breakpoint 1.1
frame #0: 0x00000000004093b0 zip`help
zip`help:
-> 0x4093b0 <+0>: pushq %r12
0x4093b2 <+2>: movq 0x2af5f(%rip), %rsi ; + 4056
0x4093b9 <+9>: movl $0x1, %edi
0x4093be <+14>: xorl %eax, %eax
Process 10073 launched: '/usr/bin/zip' (x86_64)
(lldb) bt
* thread #1, name = 'zip', stop reason = breakpoint 1.1
* frame #0: 0x00000000004093b0 zip`help
frame #1: 0x0000000000403970 zip`main + 3248
frame #2: 0x00007ffff7d8bf33 libc.so.6`__libc_start_main + 243
frame #3: 0x0000000000408cee zip`_start + 46
In order to support the .gnu_debugdata section, one has to have LZMA
development headers installed. The CMake section, that controls this
part looks for the LZMA headers and enables .gnu_debugdata support by
default if they are found; otherwise or if explicitly requested, the
minidebuginfo support is disabled.
GDB supports the "mini debuginfo" section .gnu_debugdata since v7.6
(2013).
Reviewers: espindola, labath, jankratochvil, alexshap
Reviewed By: labath
Subscribers: rnkovacs, wuzish, shafik, emaste, mgorny, arichardson, hiraditya, MaskRay, lldb-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D66791
llvm-svn: 373891
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, lit tests don't set neither the module cache for building
inferiors nor the module cache used by lldb when running tests.
Furthermore, we have several places where we rely on the path to the
module cache being always the same, rather than passing the correct
value around. This makes it hard to specify a different module cache
path when debugging a a test.
This patch reworks how we determine and pass around the module cache
paths and fixes the omission on the lit side. It also adds a sanity
check to the lit and dotest suites.
Differential revision: https://reviews.llvm.org/D66966
llvm-svn: 370394
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
On AIX psutil can run into problems with permissions to read the process
tree, which causes problems for python timeout tests which need to kill off
a test and it's children.
This patch adds a workaround by invoking shell via subprocess and using a
platform specific option to ps to list all the descendant processes so we can
kill them. We add some checks so lit can tell whether timeout tests are
supported with out exposing whether we are utilizing the psutil
implementation or the alternative.
Reviewers: hubert.reinterpretcast, andusy, davide, delcypher
Reviewed By: delcypher
Subscribers: davide, delcypher, christof, lldb-commits, libcxx-commits, llvm-commits
Tags: #lldb, #libc, #llvm
Differential Revision: https://reviews.llvm.org/D64251
llvm-svn: 366912
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D62096
llvm-svn: 361114
|
| |
|
|
|
|
|
|
| |
Apparently setting the per-test-timeout and not having the psutil
package constitutes to a fatal error. So only set the timeout when the
module is available.
llvm-svn: 359503
|
| |
|
|
|
|
|
|
| |
The timeout wasn't working because it's a property of the lit
configuration, not of the configuration in lit.site.cfg. This sets the
property for the correct object.
llvm-svn: 359492
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add a new lit-cpuid tool that detects CPU features used by some of
the tests, and use it to populate available_features in lit. For now,
this means that the test for MM/XMM register read will be run only
when the host CPU support SSE instruction set. However, this is going
to make it possible to introduce additional tests relying on AVX.
Differential Revision: https://reviews.llvm.org/D61073
llvm-svn: 359303
|
| |
|
|
|
|
|
|
|
|
|
| |
Otherwise, the clang analyzer tests fail on Windows when attempting to
unpickle AnalyzerTest objects in the worker processes. The pattern of,
add to path, import, remove from path, serialize, deserialize, doesn't
work. Once something gets added to the path, if we want to move it
across the wire for multiprocessing, we need to keep the module on
sys.path.
llvm-svn: 347254
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recently I tried to port LLDB's lit configuration files over to use a
on the surface, but broke some cases that weren't broken before and also
exposed some additional problems with the old approach that we were just
getting lucky with.
When we set up a lit environment, the goal is to make it as hermetic as
possible. We should not be relying on PATH and enabling the use of
arbitrary shell commands. Instead, only whitelisted commands should be
allowed. These are, generally speaking, the lit builtins such as echo,
cd, etc, as well as anything for which substitutions have been
explicitly set up for. These substitutions should map to the build
output directory, but in some cases it's useful to be able to override
this (for example to point to an installed tools directory).
This is, of course, how it's supposed to work. What was actually
happening is that we were bringing in PATH and LD_LIBRARY_PATH and then
just running the given run line as a shell command. This led to problems
such as finding the wrong version of clang-cl on PATH since it wasn't
even a substitution, and flakiness / non-determinism since the
environment the tests were running in would change per-machine. On the
other hand, it also made other things possible. For example, we had some
tests that were explicitly running cl.exe and link.exe instead of
clang-cl and lld-link and the only reason it worked at all is because it
was finding them on PATH. Unfortunately we can't entirely get rid of
these tests, because they support a few things in debug info that
clang-cl and lld-link don't (notably, the LF_UDT_MOD_SRC_LINE record
which makes some of the tests fail.
The high level changes introduced in this patch are:
1. Removal of functionality - The lit test suite no longer respects
LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER. This means there is no
more support for gcc, but nobody was using this anyway (note: The
functionality is still there for the dotest suite, just not the lit test
suite). There is no longer a single substitution %cxx and %cc which maps
to <arbitrary-compiler>, you now explicitly specify the compiler with a
substitution like %clang or %clangxx or %clang_cl. We can revisit this
in the future when someone needs gcc.
2. Introduction of the LLDB_LIT_TOOLS_DIR directory. This does in spirit
what LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER used to do, but now
more friendly. If this is not specified, all tools are expected to be
the just-built tools. If it is specified, the tools which are not
themselves being tested but are being used to construct and run checks
(e.g. clang, FileCheck, llvm-mc, etc) will be searched for in this
directory first, then the build output directory.
3. Changes to core llvm lit files. The use_lld() and use_clang()
functions were introduced long ago in anticipation of using them in
lldb, but since they were never actually used anywhere but their
respective problems, there were some issues to be resolved regarding
generality and ability to use them outside their project.
4. Changes to .test files - These are all just replacing things like
clang-cl with %clang_cl and %cxx with %clangxx, etc.
5. Changes to lit.cfg.py - Previously we would load up some system
environment variables and then add some new things to them. Then do a
bunch of work building out our own substitutions. First, we delete the
system environment variable code, making the environment hermetic. Then,
we refactor the substitution logic into two separate helper functions,
one which sets up substitutions for the tools we want to test (which
must come from the build output directory), and another which sets up
substitutions for support tools (like compilers, etc).
6. New substitutions for MSVC -- Previously we relied on location of
MSVC by bringing in the entire parent's PATH and letting
subprocess.Popen just run the command line. Now we set up real
substitutions that should have the same effect. We use PATH to find
them, and then look for INCLUDE and LIB to construct a substitution
command line with appropriate /I and /LIBPATH: arguments. The nice thing
about this is that it opens the door to having separate %msvc-cl32 and
%msvc-cl64 substitutions, rather than only requiring the user to run
vcvars first. Because we can deduce the path to 32-bit libraries from
64-bit library directories, and vice versa. Without these substitutions
this would have been impossible.
Differential Revision: https://reviews.llvm.org/D54567
llvm-svn: 347216
|
| |
|
|
| |
llvm-svn: 347071
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This saves about 3 redundant gigabytes from the Objective-C test build
directories. Tests that must do unsavory things with the LLDB clang
module cache, already specify a per-test module cache in their .py
test instructions.
<rdar://problem/36002081>
Differential Revision: https://reviews.llvm.org/D54602
llvm-svn: 347057
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just to be safe, up until now each test used its own Clang module
cache directory. Since the compiler within one testsuite doesn't
change it is just as safe to share a clang module directory inside the
LLDB test build directory. This saves us from compiling tens of
gigabytes of redundant Darwin and Foundation .pcm files and also
speeds up running the test suite quite significantly.
rdar://problem/36002081
Differential Revision: https://reviews.llvm.org/D54601
llvm-svn: 347056
|
|
|
A year or so ago, I re-wrote most of the lit infrastructure in LLVM so
that it wasn't so boilerplate-y. I added lots of common helper type
stuff, simplifed usage patterns, and made the code more elegant and
maintainable.
We migrated to this in LLVM, clang, and lld's lit files, but not in
LLDBs. This started to bite me recently, as the 4 most recent times I
tried to run the lit test suite in LLDB on a fresh checkout the first
thing that would happen is that python would just start crashing with
unhelpful backtraces and I would have to spend time investigating.
You can reproduce this today by doing a fresh cmake generation, doing
ninja lldb and then python bin/llvm-lit.py -sv ~/lldb/lit/SymbolFile at
which point you'll get a segfault that tells you nothing about what your
problem is.
I started trying to fix the issues with bandaids, but it became clear
that the proper solution was to just bring in the work I did in the rest
of the projects. The side benefit of this is that the lit configuration
files become much cleaner and more understandable as a result.
Differential Revision: https://reviews.llvm.org/D54009
llvm-svn: 346008
|
