Now that almost all functionality of Apple's dsymutil has been
upstreamed, the open source variant can be used as a drop in
replacement. Hence we feel it's no longer necessary to have the llvm
prefix.

Differential revision: https://reviews.llvm.org/D44527

llvm-svn: 327790

This makes 'ninja clean ; ninja check-all' work again.

llvm-svn: 327002

These tests assumes availability of external symbols provided by the
C++ library, but those won't be available in case when the C++ library
is statically linked because lli itself doesn't need these.

This uses llvm-readobj -needed-libs to check if C++ library is linked as
shared library and exposes that information as a feature to lit.

Differential Revision: https://reviews.llvm.org/D41272

llvm-svn: 321981

Detects whether we have the Python modules (pygments, yaml) required by
opt-viewer and hooks this up to REQUIRES.

This fixes https://bugs.llvm.org/show_bug.cgi?id=34129 (the lack of opt-viewer
testing).

It's also related to https://github.com/apple/swift/pull/12938 and the idea is
to expose LLVM_HAVE_OPT_VIEWER_MODULES to the Swift cmake.

Differential Revision: https://reviews.llvm.org/D40202

Fixes since the first commit:
1. Disable syntax highlighting as different versions of pygments generate
different HTML
2. Use llvm-cxxfilt from the build

llvm-svn: 319324

This reverts commit r319188.

Breaks when c++filt is not available.

llvm-svn: 319262

Detects whether we have the Python modules (pygments, yaml) required by
opt-viewer and hooks this up to REQUIRES.

This fixes https://bugs.llvm.org/show_bug.cgi?id=34129 (the lack of opt-viewer
testing).

It's also related to https://github.com/apple/swift/pull/12938 and the idea is
to expose LLVM_HAVE_OPT_VIEWER_MODULES to the Swift cmake.

Differential Revision: https://reviews.llvm.org/D40202

llvm-svn: 319188

This reverts commit r319073.

Bot fails with a mismatch that looks like pygments-generated HTML.

llvm-svn: 319146

Detects whether we have the Python modules (pygments, yaml) required by
opt-viewer and hooks this up to REQUIRES.

This fixes https://bugs.llvm.org/show_bug.cgi?id=34129 (the lack of opt-viewer
testing).

It's also related to https://github.com/apple/swift/pull/12938 and the idea is
to expose LLVM_HAVE_OPT_VIEWER_MODULES to the Swift cmake.

Differential Revision: https://reviews.llvm.org/D40202

llvm-svn: 319073

llvm-svn: 318293

FIXME: LLVM_BUILD_32_BITS should modify host_triple.
llvm-svn: 317404

I have a test that I'd like to add to llvm that demands using more than
32-bits worth of address space. This test can't be run on 32-bit systems
because they don't have enough address space. The host triple should be
used to determine this instead of config.host_arch because on Debian
systems config.host_arch is not correct. This change adds the
"host-arch-is-64bit" feature to allow tests to restrict themselves to
the 64-bit case.

Differential Revision: https://reviews.llvm.org/D39465

llvm-svn: 317281

This was causing execname-options.ll to fail on the wasm
waterfall.

Differential Revision: https://reviews.llvm.org/D39022

llvm-svn: 316123

This addresses two sources of inconsistency in test configuration
files.

1. Substitution boundaries.  Previously you would specify a
   substitution, such as 'lli', and then additionally a set
   of characters that should fail to match before and after
   the tool.  This was used, for example, so that matches that
   are parts of full paths would not be replaced.  But not all
   tools did this, and those that did would often re-invent
   the set of characters themselves, leading to inconsistency.
   Now, every tool substitution defaults to using a sane set
   of reasonable defaults and you have to explicitly opt out
   of it.  This actually fixed a few latent bugs that were
   never being surfaced, but only on accident.

2. There was no standard way for the system to decide how to
   locate a tool.  Sometimes you have an explicit path, sometimes
   we would search for it and build up a path ourselves, and
   sometimes we would build up a full command line.  Furthermore,
   there was no standardized way to handle missing tools.  Do we
   warn, fail, ignore, etc?  All of this is now encapsulated in
   the ToolSubst class.  You either specify an exact command to
   run, or an instance of FindTool('<tool-name>') and everything
   else just works.  Furthermore, you can specify an action to
   take if the tool cannot be resolved.

Differential Revision: https://reviews.llvm.org/D38565

llvm-svn: 315085

llvm-svn: 315084

There were two issues, one Python 3 specific related to Unicode,
and another which is that the tool substitution for lld no longer
rejected matches where a / preceded the tool name.

llvm-svn: 313928

This is breaking several bots.  I have enough information to
investigate, so I'm reverting to green until I get it figured
out.

llvm-svn: 313922

debuginfo-tests has need to reuse a lot of common configuration
from clang and lld, and in general it seems like all of the
projects which are tightly coupled (e.g. lld, clang, llvm, lldb,
etc) can benefit from knowing about one other.  For example,
lldb needs to know various things about how to run clang in its
test suite.  Since there's a lot of common substitutions and
operations that need to be shared among projects, sinking this
up into LLVM makes sense.

In addition, this patch introduces a function add_tool_substitution
which handles all the dirty intricacies of matching tool names
which was previously copied around the various config files.  This
is now a simple straightforward interface which is hard to mess
up.

Differential Revision: https://reviews.llvm.org/D37944

llvm-svn: 313919

Many editors and Python-related diagnostics tools such as
debuggers break or fail in mysterious ways when python files
don't end in .py.  This is especially true on Windows, but
still exists on other platforms.  I don't want to be too heavy
handed in changing everything across the board, but I do want
to at least *allow* lit configs to have .py extensions.  This
patch makes the discovery process first look for a config file
with a .py extension, and if one is not found, then looks for
a config file using the old method.  So for existing users, there
should be no functional change.

Differential Revision: https://reviews.llvm.org/D37838

llvm-svn: 313849

NFC intended here, this only updates clang and lld's lit configs
to use some helper functionality in the lit.llvm submodule.

llvm-svn: 313579

There were some issues surrounding Py2 / Py3 compatibility, but
I've now tested with both Py2 and Py3 and everything seems to
work.

llvm-svn: 313467

It looks like this is going to be non-trivial to get working
in both Py2 and Py3, so for now I'm reverting until I have time
to fully test it under Python 3.

llvm-svn: 313429

This was reverted alongside the revert of the lit/llvm-lit refactor,
but now that that has re-landed, I'm relanding this as well.

llvm-svn: 313426

This is a resubmission of r313270.  It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.

The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config.  If present, it
will generate llvm-lit into the output directory.  Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system.  This supports the use case of
someone installing lit via a package manager.  If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.

Differential Revision: https://reviews.llvm.org/D37756

llvm-svn: 313407

This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.

llvm-svn: 313335

This is breaking due to some changes I forgot to merge in, so I'm
temporarily reverting them until I can re-test that this works.

llvm-svn: 313328

To further reduce duplicate code, this patch introduces a module
that configs can simply import and get access to a lot of useful
functionality such as setting up paths, adding features that are
useful across all projects, and other utility-type functions.

For now this only updates llvm's suite to use this new library,
but subsequent patches will update other projects.

Differential Revision: https://reviews.llvm.org/D37778

llvm-svn: 313325

This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.

A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run.  However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on.  As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.

This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.

This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.

On the other hand, for us it allows us to make many simplifications:

* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
  might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=<path>
  on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
  support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
  finding a site config from the main config are now gone.

One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=<path>` parameters.  Instead, you need to run
llvm-lit.py.

Differential Revision: https://reviews.llvm.org/D37756

llvm-svn: 313270

llvm-svn: 312427

As discussed on llvm-dev I've implemented the first basic steps towards
llvm-objcopy/llvm-objtool (name pending).

This change adds the ability to copy (without modification) 64-bit
little endian ELF executables that have SHT_PROGBITS, SHT_NOBITS,
SHT_NULL and SHT_STRTAB sections.

Patch by Jake Ehrlich

Differential Revision: https://reviews.llvm.org/D33964

llvm-svn: 309643

llvm-svn: 309241

llvm-svn: 309229

llvm-svn: 309134

llvm-svn: 308685

Summary: Implement parsing and writing of a single xml manifest file.

Subscribers: mgorny, llvm-commits, hiraditya

Differential Revision: https://reviews.llvm.org/D35425

llvm-svn: 308679

Summary:
The capture() function was removed in r306625. This should fix PGO breakages
reported by Michael Zolotukhin.

Reviewers: mzolotukhin

Subscribers: sanjoy, llvm-commits

Differential Revision: https://reviews.llvm.org/D35088

llvm-svn: 307320

Older PDBs don't have this.  Its presence is detected by using
the various "feature" flags that come at the end of the PDB
Stream.  Detect this, and don't try to dump the ID stream if the
features tells us it's not present.

llvm-svn: 305235

Introduce the new feature "abi-breaking-checks" to satisfy -reverse-iterate in llvm/test/Transforms/Util/PredicateInfo/

A few tests in llvm/test/Transforms/Util/PredicateInfo/ are using -reverse-iterate.
The option -reverse-iterate is enabled with +Asserts in usual cases, but it can be turned on/off regardless of LLVM_ENABLE_ASSERTIONS.

I wonder if this were incompatible to https://reviews.llvm.org/D33908 (r304757).

Differential Revision: https://reviews.llvm.org/D33854

llvm-svn: 304851

Modify the --system-libs option in llvm-config to print system libs only
when using static linking. The system libraries are irrelevant when
linking to a shared library since the library has appropriate library
dependencies embedded.

Modify the --system-libs test appropriately to force static linking, and
disable it if static libs are not available (i.e. BUILD_SHARED_LIBS is
enabled).

Differential Revision: https://reviews.llvm.org/D27805

llvm-svn: 291285

Canonicalize all CMake booleans to 0/1 before passing them to lit, to
ensure that the Python side handles all of them consistently
and correctly. 0/1 is a safe choice of values that trigger the same
boolean interpretation in CMake, Python and C++.

Furthermore, using them without quotes improves the chance Python will
explicitly fail when an incorrect value (such as ON/OFF, TRUE/FALSE,
YES/NO) is accidentally passed, rather than silently misinterpreting
the value.

This replaces a lot of different logics spread around lit site files,
attempting to partially reproduce the boolean logic used in CMake
and usually silently failing when an uncommon value was used instead.
In fact, some of them were never working correctly since different
values were assigned in CMake and checked in Python.

The alternative solution could be to create a common parser for CMake
booleans in lit and use it consistently throughout the site files.
However, it does not seem like the best idea to create redundant
implementation of the same logic and have to follow upstream if it ever
is extended to handle more values.

Differential Revision: https://reviews.llvm.org/D28294

llvm-svn: 291284

This is a CMake var which never evaluates to false.

llvm-svn: 289673