I saw a failure on an internal bot, opened this file, saw it was missing,
thought "aha!", tried to land, got an "file is out of date", synced, didn't see
the file listed right above the line I added (cause I didn't add it in the
right place) and landed. Apologies!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224152 91177308-0d34-0410-b5e6-96231b3b80d8
The goal of this tool is to replicate Darwin's dsymutil functionality
based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does
not link the debug information, it leaves it in the object files in
relocatable form, but embbeds a `debug map` into the executable that
describes where to find the debug information and how to relocate it.
When releasing/archiving a binary, dsymutil is called to link all the DWARF
information into a `dsym bundle` that can distributed/stored along with
the binary.
With this commit, the LLVM based dsymutil is just able to parse the STABS
debug maps embedded by ld64 in linked binaries (and not all of them, for
example archives aren't supported yet).
Note that the tool directory is called dsymutil, but the executable is
currently called llvm-dsymutil. This discrepancy will disappear once the
tool will be feature complete. At this point the executable will be renamed
to dsymutil, but until then you do not want it to override the system one.
Differential Revision: http://reviews.llvm.org/D6242
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224134 91177308-0d34-0410-b5e6-96231b3b80d8
This tool lets us build LLVM components within the tree by setting up a
$GOPATH that resembles a tree fetched in the normal way with "go get".
It is intended that components such as the Go frontend will be built in-tree
using this tool.
Differential Revision: http://reviews.llvm.org/D5902
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220462 91177308-0d34-0410-b5e6-96231b3b80d8
Ugh. Turns out not even transformation passes link in how to read IR.
I sincerely believe the buildbots will finally agree with my system
after this though. (I don't really understand why all of this has been
working on my system, but not on all the buildbots.)
Create a new tool called llvm-uselistorder to use for verifying use-list
order. For now, just dump everything from the (now defunct)
-verify-use-list-order pass into the tool.
This might be a better way to test use-list order anyway.
Part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213957 91177308-0d34-0410-b5e6-96231b3b80d8
A builder complained that it couldn't find llvm-vtabledump, this is
probably because it wasn't a dependency of the 'test' target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213905 91177308-0d34-0410-b5e6-96231b3b80d8
Introducing llvm-profdata, a tool for merging profile data generated by
PGO instrumentation in clang.
- The name indicates a file extension of <name>.profdata. Eventually
profile data output by clang should be changed to that extension.
- llvm-profdata merges two profiles. However, the name is more general,
since it will likely pick up more tasks (such as summarizing a single
profile).
- llvm-profdata parses the current text-based format, but will be
updated once we settle on a binary format.
<rdar://problem/15949645>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201535 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-tblgen is not built when external LLVM_TABLEGEN is specified.
Even then, llvm-tblgen should be built for testing tblgen itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199558 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-mcmarkup, obj2yaml and yaml2obj were missing from the substitutions list,
causing the test suite to fail in a sandboxed environment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193559 91177308-0d34-0410-b5e6-96231b3b80d8
in the abstraction for lit test suites so that the various other layers
of abstraction pick up the same behavioral fix, and so that we still get
a complete list of dependencies for the 'check-all' target.
This should fix the follow-on issues of the same nature with various
other build targets, including Clang targets. Sorry for the churn, and
again thanks to Matt for testing and breaking this more thoroughly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159593 91177308-0d34-0410-b5e6-96231b3b80d8
No functionality changed here, except that the CMake installed by
default on Ubuntu Lucid should actually work with the makefile
generators now.
Thanks to Matt for the report and head-desking required to figure out
why it was failing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159588 91177308-0d34-0410-b5e6-96231b3b80d8
re-used. Also, build in direct support for accumulating a set of lit
parameters, arguments, and testsuites to run as part of a 'check-all'
rule. This sinks 'check-all' from a Clang-specific construct to
a generic construct of the project.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159482 91177308-0d34-0410-b5e6-96231b3b80d8
This is another vestige of the DejaGNU roots. There were FIXMEs in the
lit setup to add a 'lit.site.cfg', which has been around for quite some
time now, so I've properly switched the handling of the 4 things
actually used in site.exp to go through lit.site.cfg now. No more
parsing of the .exp file, one fewer configure-style generated file,
etc., etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159313 91177308-0d34-0410-b5e6-96231b3b80d8
'check-llvm'.
Don't worry! 'check' still works! =] To rationalize the names of targets
used to run tests, the vague plan is the following:
make check-llvm # run LLVM reg/unit tests (currently 'check')
make check-clang # run Clang reg/unit tests (currently 'clang-test')
make check-rt # run CompilerRT reg/unit tests
make check-asan # run ASan reg/unit tests (subset of -rt)
make check-tsan # run TSan reg/unit tests (subset of -rt)
make check-all # run as much of the above as is available
The last one respects what projects are checked out and built for
a given tree. Personally, I would like to eventually make 'check' be an
alias for 'check-all'. For now however, it is an alias for 'check-llvm',
and thus no behavior has changed.
While this patch and my plan only really apply to CMake, I think it
might be good to similarly rationalize the naming scheme for the Make
builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159258 91177308-0d34-0410-b5e6-96231b3b80d8
