Commit Graph

54 Commits

Author SHA1 Message Date
Mehdi Amini a0cb890fb6 Clean the API for CollectAsmUndefinedRefs, taking a Triple and a String InlineAsm instead of a Module (NFC)
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267106
2016-04-22 04:58:12 +00:00
Mehdi Amini 9ff43e40fa IRObjectFile, clang-format fixup for r267104
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267105
2016-04-22 04:49:46 +00:00
Mehdi Amini 9a1724bf3d Use std::move on the enum to insert it into the pair to please MSVC
(I have no idea why is it needed)
Fixup for r267103

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267104
2016-04-22 04:45:57 +00:00
Mehdi Amini e9cffafdf7 Refactor IRObjectFile, extract a static CollectAsmUndefinedRefs() method to parse inline assembly (NFC)
I plan to call this from ThinLTOCodeGenerator.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267103
2016-04-22 04:28:05 +00:00
Kevin Enderby 3fcdf6ae2a Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump to produce a real error message
Produce the first specific error message for a malformed Mach-O file describing
the problem instead of the generic message for object_error::parse_failed of
"Invalid data was encountered while parsing the file”.  Many more good error
messages will follow after this first one.

This is built on Lang Hames’ great work of adding the ’Error' class for
structured error handling and threading Error through MachOObjectFile
construction.  And making createMachOObjectFile return Expected<...> .

So to to get the error to the llvm-obdump tool, I changed the stack of
these methods to also return Expected<...> :

  object::ObjectFile::createObjectFile()
  object::SymbolicFile::createSymbolicFile()
  object::createBinary()

Then finally in ParseInputMachO() in MachODump.cpp the error can
be reported and the specific error message can be printed in llvm-objdump
and can be seen in the existing test case for the existing malformed binary
but with the updated error message.

Converting these interfaces to Expected<> from ErrorOr<> does involve
touching a number of places. To contain the changes for now use of
errorToErrorCode() and errorOrToExpected() are used where the callers
are yet to be converted.

Also there some were bugs in the existing code that did not deal with the
old ErrorOr<> return values.  So now with Expected<> since they must be
checked and the error handled, I added a TODO and a comment:
“// TODO: Actually report errors helpfully” and a call something like
consumeError(ObjOrErr.takeError()) so the buggy code will not crash
since needed to deal with the Error.

Note there is one fix also needed to lld/COFF/InputFiles.cpp that goes along
with this that I will commit right after this.  So expect lld not to built
after this commit and before the next one.

llvm-svn: 265606
2016-04-06 22:14:09 +00:00
Steven Wu f2fe0141ca Rename embedded bitcode section in MachO
Summary:
Rename the section embeds bitcode from ".llvmbc,.llvmbc" to "__LLVM,__bitcode".
The new name matches MachO section naming convention.

Reviewers: rafael, pcc

Subscribers: davide, llvm-commits, joker.eph

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

llvm-svn: 262245
2016-02-29 19:40:10 +00:00
Rafael Espindola 8d6fbc3a4e IRObject: Mark extern_weak as weak.
llvm-svn: 262222
2016-02-29 14:26:06 +00:00
Rafael Espindola cf98162574 Use copy initialization.
We can do it since getMemBuffer returns a unique_ptr.

llvm-svn: 260576
2016-02-11 19:54:18 +00:00
Benjamin Kramer b3e8a6d2b8 Move MCTargetAsmParser.h to llvm/MC/MCParser where it belongs.
llvm-svn: 258917
2016-01-27 10:01:28 +00:00
Rafael Espindola 9d2bfc4874 Use diagnostic handler in the LLVMContext
This patch converts code that has access to a LLVMContext to not take a
diagnostic handler.

This has a few advantages

* It is easier to use a consistent diagnostic handler in a single program.
* Less clutter since we are not passing a handler around.

It does make it a bit awkward to implement some C APIs that return a
diagnostic string. I will propose new versions of these APIs and
deprecate the current ones.

llvm-svn: 255571
2015-12-14 23:17:03 +00:00
Kevin Enderby dc0dbe1f69 Fix llvm-nm(1) printing of llvm-bitcode files for -format darwin to match darwin’s nm(1).
Also a small fix to match printing of Mach-O objects with -format posix.

llvm-svn: 252567
2015-11-10 00:31:08 +00:00
Rafael Espindola c233f74e6e Simplify the Mangler interface now that DataLayout is mandatory.
We only need to pass in a DataLayout when mangling a raw string, not when
constructing the mangler.

llvm-svn: 240405
2015-06-23 13:59:29 +00:00
Rafael Espindola dcd1dca275 Return a unique_ptr from getLazyBitcodeModule and parseBitcodeFile. NFC.
llvm-svn: 239858
2015-06-16 22:27:55 +00:00
Daniel Sanders 8d8b13dc19 Recommit r239721: Replace string GNU Triples with llvm::Triple in InitMCObjectFileInfo. NFC.
Summary:
This affects other tools so the previous C++ API has been retained as a
deprecated function for the moment. Clang has been updated with a trivial
patch (not covered by the pre-commit review) to avoid breaking -Werror builds.
Other in-tree tools will be fixed with similar patches.

This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.

The first time this was committed it accidentally fixed an inconsistency in
triples in llvm-mc and this caused a failure. This inconsistency was fixed in
r239808.

Reviewers: rengolin

Reviewed By: rengolin

Subscribers: llvm-commits, rengolin

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

llvm-svn: 239812
2015-06-16 12:18:07 +00:00
Daniel Sanders fa555dc7f8 Revert r239721 - Replace string GNU Triples with llvm::Triple in InitMCObjectFileInfo. NFC.
It appears to cause sparc-little-endian.s to assert on Windows and Darwin.

llvm-svn: 239724
2015-06-15 10:34:38 +00:00
Daniel Sanders d6d12a1192 Replace string GNU Triples with llvm::Triple in InitMCObjectFileInfo. NFC.
Summary:
This affects other tools so the previous C++ API has been retained as a
deprecated function for the moment. Clang has been updated with a trivial
patch (not covered by the pre-commit review) to avoid breaking -Werror builds.
Other in-tree tools will be fixed with similar trivial patches.

This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.

Reviewers: rengolin

Reviewed By: rengolin

Subscribers: llvm-commits, rengolin

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

llvm-svn: 239721
2015-06-15 09:19:41 +00:00
Peter Collingbourne 82e657b509 Object: Prepend __imp_ when mangling a dllimport symbol in IRObjectFile.
We cannot prepend __imp_ in the IR mangler because a function reference may
be emitted unmangled in a constant initializer. The linker is expected to
resolve such references to thunks. This is covered by the new test case.

Strictly speaking we ought to emit two undefined symbols, one with __imp_ and
one without, as we cannot know which symbol the final object file will refer
to. However, this would require rather intrusive changes to IRObjectFile,
and lld works fine without it for now.

This reimplements r239437, which was reverted in r239502.

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

llvm-svn: 239560
2015-06-11 21:42:18 +00:00
Rui Ueyama 7d09919534 Remove object_error::success and use std::error_code() instead
make_error_code(object_error) is slow because object::object_category()
uses a ManagedStatic variable. But the real problem is that the function is
called too frequently. This patch uses std::error_code() instead of
object_error::success. In most cases, we return "success", so this patch
reduces number of function calls to that function.

http://reviews.llvm.org/D10333

llvm-svn: 239409
2015-06-09 15:20:42 +00:00
Pete Cooper 81902a3ae4 Remove MCAssembler.h include from MCStreamer.h and fix users of MCStreamer.h
llvm-svn: 237483
2015-05-15 22:19:42 +00:00
Rafael Espindola cba833a09d Be lazy about loading metadata in IRObjectFile.
This speeds up llvm-ar building lib64/libclangSema.a with debug IR files
from 8.658015807 seconds to just 0.351036519 seconds :-)

llvm-svn: 232221
2015-03-13 21:54:20 +00:00
Mehdi Amini 46a43556db Make DataLayout Non-Optional in the Module
Summary:
DataLayout keeps the string used for its creation.

As a side effect it is no longer needed in the Module.
This is "almost" NFC, the string is no longer
canonicalized, you can't rely on two "equals" DataLayout
having the same string returned by getStringRepresentation().

Get rid of DataLayoutPass: the DataLayout is in the Module

The DataLayout is "per-module", let's enforce this by not
duplicating it more than necessary.
One more step toward non-optionality of the DataLayout in the
module.

Make DataLayout Non-Optional in the Module

Module->getDataLayout() will never returns nullptr anymore.

Reviewers: echristo

Subscribers: resistor, llvm-commits, jholewinski

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 231270
2015-03-04 18:43:29 +00:00
Benjamin Kramer 0a446fd56c Add missing includes. make_unique proliferated everywhere.
llvm-svn: 230909
2015-03-01 21:28:53 +00:00
Peter Collingbourne 20c7259ce9 Introduce Target::createNullTargetStreamer and use it from IRObjectFile.
A null MCTargetStreamer allows IRObjectFile to ignore target-specific
directives. Previously we were crashing.

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

llvm-svn: 229797
2015-02-19 00:45:02 +00:00
Chandler Carruth d9903888d9 [cleanup] Re-sort all the #include lines in LLVM using
utils/sort_includes.py.

I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.

llvm-svn: 225974
2015-01-14 11:23:27 +00:00
Michael Ilseman addddc441f Silence more static analyzer warnings.
Add in definedness checks for shift operators, null checks when
pointers are assumed by the code to be non-null, and explicit
unreachables.

llvm-svn: 224255
2014-12-15 18:48:43 +00:00
Rafael Espindola 5dec7eaae2 Rename createIRObjectFile to just create.
It is a static method of IRObjectFile, so having to use
IRObjectFile::createIRObjectFile was redundant.

llvm-svn: 223822
2014-12-09 20:36:13 +00:00
Rafael Espindola 25a7e0a89f Move method out of line to make buildbot happy.
llvm-svn: 223781
2014-12-09 16:18:11 +00:00
Rafael Espindola 527e846ef7 Don't lookup an object symbol name in the module.
Instead, walk the obj symbol list in parallel to find the GV. This shouldn't
change anything on ELF where global symbols are not mangled, but it is a step
toward supporting other object formats.

Gold itself is ELF only, but bfd ld supports COFF and the logic in the gold
plugin could be reused on lld.

llvm-svn: 223780
2014-12-09 16:13:59 +00:00
Rafael Espindola d4bcefc7d9 Don't ever call materializeAllPermanently during LTO.
To do this, change the representation of lazy loaded functions.

The previous representation cannot differentiate between a function whose body
has been removed and one whose body hasn't been read from the .bc file. That
means that in order to drop a function, the entire body had to be read.

llvm-svn: 220580
2014-10-24 18:13:04 +00:00
Peter Collingbourne 10039c02ea 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
2014-09-18 21:28:49 +00:00
David Blaikie 10a27df8ff 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
2014-09-03 17:59:23 +00:00
Rafael Espindola 688121571a Pass a && to getLazyBitcodeModule.
This forces callers to use std::move when calling it. It is somewhat odd to have
code with std::move that doesn't always move, but it is also odd to have code
without std::move that sometimes moves.

llvm-svn: 217049
2014-09-03 17:31:46 +00:00
Rafael Espindola e2c1d77fb4 Pass a std::unique_ptr<MemoryBuffer>& to getLazyBitcodeModule.
By taking a reference we can do the ownership transfer in one place instead of
expecting every caller to do it.

llvm-svn: 216492
2014-08-26 22:00:09 +00:00
Rafael Espindola d96d553d76 Pass a MemoryBufferRef when we can avoid taking ownership.
The attached patch simplifies a few interfaces that don't need to take
ownership of a buffer.

For example, both parseAssembly and parseBitcodeFile will parse the
entire buffer before returning. There is no need to take ownership.

Using a MemoryBufferRef makes it obvious in the type signature that
there is no ownership transfer.

llvm-svn: 216488
2014-08-26 21:49:01 +00:00
David Blaikie 1961f14cf9 Explicitly pass ownership of the MemoryBuffer to AddNewSourceBuffer using std::unique_ptr
llvm-svn: 216223
2014-08-21 20:44:56 +00:00
Rafael Espindola 48af1c2a1a 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
2014-08-19 18:44:46 +00:00
Rafael Espindola ba79dba8ed Make RecordStreamer.h private.
llvm-svn: 212361
2014-07-04 22:44:18 +00:00
Rafael Espindola 2dc0d9bddb Ignore llvm.* globals.
It is not clear if llvm.global_ctors should or should not be in llvm.metadata,
but in practice it is not and we need to ignore it for LTO.

llvm-svn: 212351
2014-07-04 19:08:22 +00:00
Rafael Espindola dddd1fd9f4 Implement LTOModule on top of IRObjectFile.
IRObjectFile provides all the logic for producing mangled names and getting
symbols from inline assembly.

LTOModule then adds logic for linking specific tasks, like constructing
llvm.compiler_user or extracting linker options from the bitcode.

The rule of the thumb is that IRObjectFile has the functionality that is
needed by both LTO and llvm-ar.

llvm-svn: 212349
2014-07-04 18:40:36 +00:00
Rafael Espindola 3885090b86 Mark intrinsic functions as llvm-specific.
llvm-svn: 212347
2014-07-04 15:58:00 +00:00
Rafael Espindola b674c17deb Don't include llvm.metadata variables in archive symbol tables.
llvm-svn: 212344
2014-07-04 15:03:17 +00:00
Rafael Espindola 30f37f5fc4 Move createIRObjectFile to the IRObjectFile class and return the concrete type.
llvm-svn: 212301
2014-07-03 23:03:50 +00:00
Rafael Espindola 13b69d63e6 Add support for inline asm symbols to IRObjectFile.
This also enables it in llvm-nm so that it can be tested.

llvm-svn: 212282
2014-07-03 18:59:23 +00:00
Rafael Espindola 2e60ca964c 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
2014-06-24 13:56:32 +00:00
Rafael Espindola c3f9b5a534 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
2014-06-23 21:53:12 +00:00
Rafael Espindola 8af5cb2c28 Change IRObjectFile to parse the bitcode lazily.
The main point of this class is to provide a cheap object interface to a bitcode
file, so it has to be as lazy as possible.

llvm-svn: 211207
2014-06-18 19:05:24 +00:00
Rafael Espindola db4ed0bdab Remove 'using std::errro_code' from lib.
llvm-svn: 210871
2014-06-13 02:24:39 +00:00
Rafael Espindola 3acea39853 Don't use 'using std::error_code' in include/llvm.
This should make sure that most new uses use the std prefix.

llvm-svn: 210835
2014-06-12 21:46:39 +00:00
Rafael Espindola 2fb5bc33a3 Remove the linker_private and linker_private_weak linkages.
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:

* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.

It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.

With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.

The objc uses are currently split in

* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.

The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are

* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.

Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.

For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).

llvm-svn: 203866
2014-03-13 23:18:37 +00:00
Ahmed Charles 56440fd820 Replace OwningPtr<T> with std::unique_ptr<T>.
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.

llvm-svn: 203083
2014-03-06 05:51:42 +00:00