There's no need to specify a flag to omit frame pointer elimination on non-leaf
nodes...(Honestly, I can't parse that option out.) Use the function attribute
stuff instead.

llvm-svn: 187093

The main observation is that we never need both the filesize and the map size.
When mapping a slice of a file, it doesn't make sense to request a null
terminator and that would be the only case where the filesize would be used.

There are other cleanups that should be done in this area:

* A client should not have to pass the size (even an explicit -1) to say if
  it wants a null terminator or not, so we should probably swap the argument
  order.
* The default should be to not require a null terminator. Very few clients
  require this, but many end up asking for it just because it is the default.

llvm-svn: 186984

The gold plugin was passing the desired map size as the file size. This was
working for two reasons:
* Recent version of gold provide the get_view callback, so this code was not
  used.
* In older versions, getOpenFile was called, but the file size is never used
  if we don't require null terminated buffers and map size defaults to the
  file size.

Thanks to Eli Bendersky for noticing this.

I will try to make this api a bit less error prone.

llvm-svn: 186978

llvm-svn: 186935

The symbol table has forward references in the file. Instead of allocating
a temporary buffer or counting the size and then writing, this implementation
writes a dummy value first and patches it once the final value is known.

There is room for performance improvement. I will implement them as soon as I
get some other features (like a ranlib mode) in.

llvm-svn: 186934

llvm-svn: 186931

 Use the function attributes to pass along the stack protector buffer size.

 Now that we have robust function attributes, don't use a command line option to
 specify the stack protecto buffer size.

llvm-svn: 186863

There already have two "dead" functions, initialize{IPO|IPA}, defined for 
similar purpose. I decide not to call these two functions for two reasons:
  o. they don't cover all LTO passes (which will soon be separated into IPO 
     and post-IPO passes)
  o. We have not yet figured out the right passes and the ordering for IPO 
     and post-IPO stages, meaning this change is only for the time being.

Since LTO passes are registered, we are now able to print IR before and 
after particular point.

For OSX users:
--------------
  "...-Wl,-mllvm -Wl,-print-after=<pass-name>" will print IR after the
  specified pass.

For Other UNIX with GNU gold linker:
------------------------------------
  "-Wl,-plugin-opt=-print-after=<pass-name>" should work.
  (NOTE: no need for "-Wl,-mllvm")

  Strip "-Wl," if flags are fed directly to linker instead of clang/clang++.

llvm-svn: 186853

This matches gnu archive behavior and since archive member order can change
which member is used, not changing the order on replacement looks like the
right thing to do.

This patch also refactors the logic for which archive member to keep and
whether to move it to a helper function (computeInsertAction). The
nesting in computeNewArchiveMembers was getting a bit confusing.

llvm-svn: 186829

We were incorrectly computing where to insert a member if it was replacing
a previous member that was before the insert point.

llvm-svn: 186792

The original change was rolled back in r186627 because of test
failures on the big endian machine. I believe I fixed the issue
so re-submitting.

llvm-svn: 186734

We were only handling the 'a' and 'b' options during moves before.

llvm-svn: 186721

This allows "llvm-mc -disassemble" to accept two new features:
  + Using comma as a byte separator
  + Grouping bytes with '[' and ']' pairs.

The behaviour outside a [...] group is unchanged. But within the group once
llvm-mc encounters a true error, it stops rather than trying to resynchronise
the stream at the next byte. This is more useful for disassembly tests, where
we have an almost-instruction in mind and don't care what the misaligned
interpretation would be. Particularly if it means llvm-mc won't actually see
the next intended almost-instruction.

As a side effect, this means llvm-mc can disassemble its own -show-encoding
output if copy-pasted.

llvm-svn: 186661

Because it broke s390x and ppc64-linux buildbots. This reverts commit r186623.

llvm-svn: 186627

Summary:
Dump optional data directory entries in the PE/COFF header, so that
we can test the output of LLD linker. This patch updates the test binary
file, but the source of the binary is the same. I just re-linked the file.
I don't know how the previous file was linked, but the previous file did
not have any data directory entries for some reason.

Reviewers: rafael

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1148

llvm-svn: 186623

llvm-ar: doExtract(): Write extracted files with F_Binary. It should fix llvm/test/Object/extract.ll

llvm-svn: 186503

llvm-svn: 186494

llvm-svn: 186493

This centralizes the handling of O_BINARY and opens the way for hiding more
differences (like how open behaves with directories).

llvm-svn: 186447

With this change llvm-ar can remove the temporary file on windows too.

llvm-svn: 186423

llvm-svn: 186381

This is a micro optimization. Instead of going char*->StringRef->Twine->char*,
go char*->Twine->char* and avoid having to copy the filename on the stack.

llvm-svn: 186380

Looks like on mingw we get bogus last modification times on directories.
Should fix the mingw bots.

llvm-svn: 186240

llvm-svn: 186239

original message:
Fix a off by one error about which members need to use the string table.

llvm-svn: 186238

  http://lab.llvm.org:8013/builders/clang-x86_64-darwin11-nobootstrap-RAincremental/builds/4328

Original commit log:
  Use the function attributes to pass along the stack protector buffer
  size.

llvm-svn: 186234

  http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/6897/steps/check-all/logs/LLVM%3A%3Aarchive-format.test

Original commit log:
  Fix a off by one error about which members need to use the string
  table.

llvm-svn: 186232

Now that we have robust function attributes, don't use a command line option to
specify the stack protecto buffer size.

llvm-svn: 186217

llvm-svn: 186216

llvm-svn: 186200

llvm-svn: 186198

This fixes two bugs is lib/Object that the use in llvm-ar found:
* In OS X created archives, the name can be padded with nulls. Strip them.
* In the constructor, remember the first non special member and use that in
  begin_children. This makes sure we skip all special members, not just the
  first one.

The change to llvm-ar itself consist of
* Using lib/Object for reading archives instead of ArchiveReader.cpp.
* Writing the modified archive directly, instead of creating an in memory
  representation.

The old Archive library was way more general than what is needed, as can
be seen by the diffstat of this patch.

Having llvm-ar using lib/Object now opens the way for creating regular symbol
tables for both native objects and bitcode files so that we can use those
archives for LTO.

llvm-svn: 186197

llvm-svn: 186170

llvm-svn: 186131

llvm-svn: 186113

llvm-svn: 186094

While at it, use strftime on Unix too and use the thread safe versions
of localtime.

llvm-svn: 186090

* It is not present on OS X.
* It is untested.
* It is not needed for using ar in a build system.

llvm-svn: 186080

llvm-svn: 186079

* All systems we support have some form of long name support.
* The options has different names and semantics in different implementations
  ('f' on gnu, 'T' on OS X), which makes it unlikely it is normally used on
  build systems.
* It was completely untested.

llvm-svn: 186078