Re-apply r246276 - Object: Teach llvm-ar to create symbol table for COFF short import files

This patch includes a fix for a llvm-readobj test. With this patch,
the tool does no longer print out COF

Re-apply r246276 - Object: Teach llvm-ar to create symbol table for COFF short import files

This patch includes a fix for a llvm-readobj test. With this patch,
the tool does no longer print out COFF headers for the short import
file, but that's probably desirable because the header for the short
import file is dummy.

llvm-svn: 246283

show more ...

Rollback r246276 - Object: Teach llvm-ar to create symbol table for COFF short import files

This change caused a test for llvm-readobj to fail.

llvm-svn: 246277

Object: Teach llvm-ar to create symbol table for COFF short import files.

COFF short import files are special kind of files that contains only
DLL-exported symbol names. That's different from object

Object: Teach llvm-ar to create symbol table for COFF short import files.

COFF short import files are special kind of files that contains only
DLL-exported symbol names. That's different from object files because
it has no data except symbol names.

This change implements a SymbolicFile interface for the short import
files so that symbol names can be accessed through that interface.
llvm-ar is now able to read the file and create symbol table entries
for short import files.

llvm-svn: 246276

show more ...

Object: Handle Mach-O kext bundle files

This particular subtype of Mach-O was missing. Add it.

llvm-svn: 230567

Rename createIRObjectFile to just create.

It is a static method of IRObjectFile, so having to use
IRObjectFile::createIRObjectFile was redundant.

llvm-svn: 223822

Support ELF files of unknown type.

llvm-svn: 222208

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) sec

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

llvm-svn: 218078

show more ...

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 f

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.

llvm-svn: 217056

show more ...

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 convertibl

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.

llvm-svn: 217048

show more ...

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

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.

llvm-svn: 216002

show more ...

Use std::unique_ptr to make the ownership explicit.

llvm-svn: 214377

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.

llvm-svn: 211595

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 constru

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.

llvm-svn: 211546

show more ...

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 t

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.

llvm-svn: 211542

show more ...

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-

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.

llvm-svn: 201881

show more ...