No intended functionality change.

llvm-svn: 185832

This fixes a regression introduced by r185726: the new call to get
a unique file does not prepend the system temporary directory, so
we need to anchor on the file that the temporary file gets moved
to to ensure we're on the same file system.

llvm-svn: 185825

I wish we could typecheck llvm::format.

llvm-svn: 185766

llvm-svn: 185751

This function is complementary to createTemporaryFile. It handles the case were
the unique file is *not* temporary: we will rename it in the end. Since we
will rename it, the file has to be in the same filesystem as the final
destination and we don't prepend the system temporary directory.

This has a small semantic difference from unique_file: the default mode is 0666.
This matches the behavior of most unix tools. For example, with this change
lld now produces files with the same permissions as ld. I will add a test
of this change when I port clang over to createUniqueFile (next commit).

llvm-svn: 185726

llvm-svn: 185719

llvm-svn: 185697

llvm-svn: 185695

parseCommandLine prints and error and exists if no operation is specified, so
it never returns NoOperation.

llvm-svn: 185691

We really want bitcode files to behave as regular object files in archives, so
we don't need to track that a member is bitcode.

llvm-svn: 185681

This is a small compatibility improvement with gnu nm and makes llvm-nm more
useful as a testing tool.

llvm-svn: 185546

This is dead code since PIC16 was removed in 2010. The result was an odd mix,
where some parts would carefully pass it along and others would assert it was
zero (most of the object streamer for example).

llvm-svn: 185436

FIXME: Could we use llvm::sys::Path here?
llvm-svn: 185322

This kind of simplification is sometimes useful, but in general it's not correct. 

As GNU/kFreeBSD is an hybrid system, for kernel-related issues we want to match the
build definitions used for FreeBSD, whereas for userland-related issues we want to
match the definitions used for other systems with Glibc.

The current modification adjusts the build system so that they can be distinguished,
and explicitly adds GNU/kFreeBSD to the build checks in which it belongs.

Fixes bug #16444.

Patch by Robert Millan in the context of Debian.

llvm-svn: 185311

- warn users when -debug-ir is used with old JIT engine (only partial debug
  info is available) 

For example, to debug an IR file with GDB (that supports JIT registration), do:

$ gdb --args lli -use-mcjit -debug-ir testcase.ll
(gdb) break main
(gdb) run
<Process continues to lli main>
(gdb) continue
<Process continues to testcase.ll main()
(gdb) step
<Now stepping through the LLVM IR in testcase.ll>

llvm-svn: 185197

sys::fs::unique_file will now loop infinitely if provided with a file name
without '%' characters and the input file already exists. As a result, bugpoint
cannot use a fixed file name for the execution output (including the reference
output).

llvm-svn: 185166

llvm-svn: 185154

llvm-svn: 185151

llvm-svn: 185143

llvm-svn: 185137

No functionality change.
It should suffice to check the type of a debug info metadata, instead of
calling Verify. For cases where we know the type of a DI metadata, use
assert.

Also update testing cases to make them conform to the format of DI classes.

llvm-svn: 185135

This reverts commit r185020

llvm-svn: 185032

No functionality change.
It should suffice to check the type of a debug info metadata, instead of
calling Verify.

llvm-svn: 185020

Patch by 罗勇刚(Yonggang Luo).

llvm-svn: 184971

llvm itself is now PathV1 clean.

llvm-svn: 184947

Where a source tree is complete with lld, lldb and polly, it may not be possible to use cmake to configure build scripts if the host compiler it not capable of compiling these sub-projects.  This change makes it possible to first build a bootstrap clang compiler when can then be used to build a complete llvm toolchain.  An example bootstrap build sequence could be as follows:

$ mkdir bootstrap
$ cd bootstrap
$ cmake -G 'Unix Makefiles'
        -DCMAKE_BUILD_TYPE:STRING=Release
        -DCMAKE_PREFIX_PATH:STRING=$(pwd)
        -DLLVM_TARGETS_TO_BUILD:STRING=host
        -DLLVM_INCLUDE_TOOLS:STRING=bootstrap-only
        ../source
$ make clang  # build clang only for host

$ cd ..
$ export CC=$(realpath bootstrap/bin)/clang
$ export CXX=$(realpath bootstrap/bin)/clang++

$ mkdir final
$ cd final
$ cmake -G 'Unix Makefiles' ../source
$ make all check-all

llvm-svn: 184924

I will remove the V1 version as soon as I change clang in the next commit.

llvm-svn: 184914

llvm-svn: 184853

llvm-svn: 184826

Removes the last use of PathV1.h in llvm-ar.

llvm-svn: 184630

Although in reality the symbol table in ELF resides in a section, the
standard requires that there be no more than one SHT_SYMTAB. To enforce
this constraint, it is cleaner to group all the symbols under a
top-level `Symbols` key on the object file.

llvm-svn: 184627

The full ELFYAML::Section isn't needed.

llvm-svn: 184626

Just add them to the vector of section headers like the rest of the
section headers.

llvm-svn: 184624

llvm-svn: 184623

The improperly aligned section content in the output was causing
buildbot failures. This should fix them.

Incidentally, this results in a simpler and more robust API for
ContiguousBlobAccumulator.

llvm-svn: 184621

llvm-svn: 184599

Previously we unconditionally enforced that section references in
symbols in the YAML had a name that was a section name present in the
object, and linked the references to that section. Now, permit empty
section names (already the default, if the `Section` key is not
provided) to indicate SHN_UNDEF.

llvm-svn: 184513

llvm-svn: 184508

Instead, just have 3 sub-lists, one for each of
{STB_LOCAL,STB_GLOBAL,STB_WEAK}.

This allows us to be a lot more explicit w.r.t. the symbol ordering in
the object file, because if we allowed explicitly setting the STB_*
`Binding` key for the symbol, then we might have ended up having to
shuffle STB_LOCAL symbols to the front of the list, which is likely to
cause confusion and potential for error.

Also, this new approach is simpler ;)

llvm-svn: 184506

llvm-svn: 184486