Commit Graph

11 Commits

Author SHA1 Message Date
Rafael Espindola
075a8cee5d Rename createIRObjectFile to just create.
It is a static method of IRObjectFile, so having to use
IRObjectFile::createIRObjectFile was redundant.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223822 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 20:36:13 +00:00
Michael J. Spencer
b9f39bcc82 Support ELF files of unknown type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222208 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-18 01:14:25 +00:00
Peter Collingbourne
394be6c159 LTO: introduce object file-based on-disk module format.
This format is simply a regular object file with the bitcode stored in a
section named ".llvmbc", plus any number of other (non-allocated) sections.

One immediate use case for this is to accommodate compilation processes
which expect the object file to contain metadata in non-allocated sections,
such as the ".go_export" section used by some Go compilers [1], although I
imagine that in the future we could consider compiling parts of the module
(such as large non-inlinable functions) directly into the object file to
improve LTO efficiency.

[1] http://golang.org/doc/install/gccgo#Imports

Differential Revision: http://reviews.llvm.org/D4371

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218078 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-18 21:28:49 +00:00
David Blaikie
faa7461fc3 unique_ptrify IRObjectFile::createIRObjectFile
I took a guess at the changes to the gold plugin, because that doesn't
seem to build by default for me. Not sure what dependencies I might be
missing for that.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217056 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-03 17:59:23 +00:00
David Blaikie
38a4f3bbec Ensure ErrorOr cannot implicitly invoke explicit ctors of the underlying type.
An unpleasant surprise while migrating unique_ptrs (see changes in
lib/Object): ErrorOr<int*> was implicitly convertible to
ErrorOr<std::unique_ptr<int>>.

Keep the explicit conversions otherwise it's a pain to convert
ErrorOr<int*> to ErrorOr<std::unique_ptr<int>>.

I'm not sure if there should be more SFINAE on those explicit ctors (I
could check if !is_convertible && is_constructible, but since the ctor
has to be called explicitly I don't think there's any need to disable
them when !is_constructible - they'll just fail anyway. It's the
converting ctors that can create interesting ambiguities without proper
SFINAE). I had to SFINAE the explicit ones because otherwise they'd be
ambiguous with the implicit ones in an explicit context, so far as I
could tell.

The converting assignment operators seemed unnecessary (and similarly
buggy/dangerous) - just rely on the converting ctors to convert to the
right type for assignment instead.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217048 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-03 17:31:25 +00:00
Rafael Espindola
548f2b6e8f Don't own the buffer in object::Binary.
Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.

Keeping this ownership would make supporting IR inside native objects
particularly painful.

This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.

This patch introduces a few new types.

* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
  This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
  for convenience functions that take a filename and return both the
  buffer and the Binary using that buffer.

The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216002 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 18:44:46 +00:00
Rafael Espindola
79002da926 Use std::unique_ptr to make the ownership explicit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214377 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-31 03:12:45 +00:00
Rafael Espindola
0d50598d71 Pass a unique_ptr<MemoryBuffer> to the constructors in the Binary hierarchy.
Once the objects are constructed, they own the buffer. Passing a unique_ptr
makes that clear.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211595 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-24 13:56:32 +00:00
Rafael Espindola
b138caba43 Pass a std::unique_ptr& to the create??? methods is lib/Object.
This makes the buffer ownership on error conditions very natural. The buffer
is only moved out of the argument if an object is constructed that now
owns the buffer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211546 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-23 22:00:37 +00:00
Rafael Espindola
1f659329b6 Make ObjectFile and BitcodeReader always own the MemoryBuffer.
This allows us to just use a std::unique_ptr to store the pointer to the buffer.
The flip side is that they have to support releasing the buffer back to the
caller.

Overall this looks like a more efficient and less brittle api.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211542 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-23 21:53:12 +00:00
Rafael Espindola
91f86b7e1c Add a SymbolicFile interface between Binary and ObjectFile.
This interface allows IRObjectFile to be implemented without having dummy
methods for all section and segment related methods.

Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is
still not plugged in since it requires some refactoring to make a Module hold
a DataLayout.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201881 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-21 20:10:59 +00:00