Commit Graph

2026 Commits

Author SHA1 Message Date
Kevin Enderby 7bd8d99497 Thread Expected<...> up from libObject’s getType() for symbols to allow llvm-objdump to produce a good error message.
Produce another specific error message for a malformed Mach-O file when a symbol’s
section index is more than the number of sections.  The existing test case in test/Object/macho-invalid.test
for macho-invalid-section-index-getSectionRawName now reports the error with the message indicating
that a symbol at a specific index has a bad section index and that bad section index value.

Again converting interfaces to Expected<> from ErrorOr<> does involve
touching a number of places. Where the existing code reported the error with a
string message or an error code it was converted to do the same.

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(NameOrErr.takeError()) so the buggy code will not crash
since needed to deal with the Error.

llvm-svn: 268298
2016-05-02 20:28:12 +00:00
Lang Hames 2307f405cc [ORC] Save AArch64 NEON state in the JIT reentry block.
The earlier version of the resolver code did not save NEON state, so it would
have broken any callees that used floating point.

llvm-svn: 268173
2016-05-01 00:14:45 +00:00
Lang Hames f74e93b600 [Orc] Add ORC lazy-compilation support for AArch64.
The ORC compile callbacks and indirect stubs APIs will now work for AArc64,
allowing functions to be lazily compiled and/or updated.

llvm-svn: 268112
2016-04-29 21:32:00 +00:00
Chaoren Lin 49317f2d90 Use llvm:Twine instead of std::to_string.
std::to_string is not available from the Android NDK.

Reviewers: lhames, ovyalov, chandlerc

Subscribers: llvm-commits

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

llvm-svn: 267829
2016-04-28 00:49:37 +00:00
Lang Hames f88174dd80 [RuntimeDyld] Propagate another dropped error in RuntimeDyldELF.
This should fix the PPC64 bots.

llvm-svn: 267810
2016-04-27 22:54:03 +00:00
Lang Hames bc38ea9596 [RuntimeDyld] Add missing include - <string> is requried for std::to_string.
This should fix the compile error that showed up in build:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-buildserver/builds/6754/

llvm-svn: 267790
2016-04-27 20:54:49 +00:00
Lang Hames 09a74c46ec [RuntimeDyld] Propagate Errors from findPPC64TOCSection.
llvm-svn: 267789
2016-04-27 20:51:58 +00:00
Lang Hames 8959531c51 [RuntimeDyld] Plumb Error/Expected through the internals of RuntimeDyld.
Also replaces a number of calls to report_fatal_error with Error returns.

The plumbing will make it easier to return errors originating in libObject.

Replacing report_fatal_errors with Error returns will give JIT clients the
opportunity to recover gracefully when the JIT is unable to produce/relocate
code, as well as providing meaningful error messages that can be used to file
bug reports.

llvm-svn: 267776
2016-04-27 20:24:48 +00:00
Lang Hames 1fa0e0e006 [ORC] clang-format code that was touched in r267457. NFC.
Commit r267457 made a lot of type-substitutions threw off code formatting and
alignment. This patch should tidy those changes up.

llvm-svn: 267475
2016-04-25 21:21:20 +00:00
Lang Hames ef5a0ee2c3 [ORC] Thread Error/Expected through the RPC library.
This replaces use of std::error_code and ErrorOr in the ORC RPC support library
with Error and Expected. This required updating the OrcRemoteTarget API, Client,
and server code, as well as updating the Orc C API.

This patch also fixes several instances where Errors were dropped.

llvm-svn: 267457
2016-04-25 19:56:45 +00:00
Davide Italiano cefdf238e9 [RuntimeDyldELF] Handle GOTPCRELX/REX_GOTPCRELX.
llvm-svn: 267309
2016-04-24 01:36:37 +00:00
Lang Hames 543e0dcc0a [RuntimeDyld] Fix conservative over-allocation of memory for common symbols.
The previous allocation code was over-estimating the amount of memory required.

No test case: we don't currently have a good way to detect conervative
over-allocation.

llvm-svn: 267041
2016-04-21 20:08:06 +00:00
Kevin Enderby d4eaa74693 Fix another compilation error from r266919 for clang-atom-d525-fedora-rel which
is another place that libObject’s getName() for symbols returns Expected<...>
that needed to be updated.

llvm-svn: 266933
2016-04-20 23:10:14 +00:00
Kevin Enderby 81e8b7d949 Thread Expected<...> up from libObject’s getName() for symbols to allow llvm-objdump to produce a good error message.
Produce another specific error message for a malformed Mach-O file when a symbol’s
string index is past the end of the string table.  The existing test case in test/Object/macho-invalid.test
for macho-invalid-symbol-name-past-eof now reports the error with the message indicating
that a symbol at a specific index has a bad sting index and that bad string index value.
 
Again converting interfaces to Expected<> from ErrorOr<> does involve
touching a number of places. Where the existing code reported the error with a
string message or an error code it was converted to do the same.  There is some
code for this that could be factored into a routine but I would like to leave that for
the code owners post-commit to do as they want for handling an llvm::Error.  An
example of how this could be done is shown in the diff in
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h which had a Check() routine
already for std::error_code so I added one like it for llvm::Error .

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(NameOrErr.takeError()) so the buggy code will not crash
since needed to deal with the Error.

Note there fixes needed to lld 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: 266919
2016-04-20 21:24:34 +00:00
Lang Hames 3fde652e18 [Orc] Re-commit r266581 with fixes for MSVC, and format cleanups.
Fixes:

(1) Removes constexpr (unsupported in MSVC)
(2) Move constructors (remove explicitly defaulted ones)
(3) <future> - Add warning suppression for MSVC.

llvm-svn: 266663
2016-04-18 19:55:43 +00:00
Nico Weber ca94d0ec0c Revert 266581 (and follow-up 266588), it doesn't build on Windows.
Three problems:
1. <future> can't be easily used.  If you must use it, see
   include/Support/ThreadPool.h for how.
2. constexpr problems, even after 266588.
3. Move assignment operators can't be defaulted in MSVC2013.

llvm-svn: 266615
2016-04-18 13:57:08 +00:00
Mehdi Amini b550cb1750 [NFC] Header cleanup
Removed some unused headers, replaced some headers with forward class declarations.

Found using simple scripts like this one:
clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap'

Patch by Eugene Kosov <claprix@yandex.ru>

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266595
2016-04-18 09:17:29 +00:00
Lang Hames 236cea74df [ORC] Generalize the ORC RPC utils to support RPC function return values and
asynchronous call/handle. Also updates the ORC remote JIT API to use the new
scheme.

The previous version of the RPC tools only supported void functions, and
required the user to manually call a paired function to return results. This
patch replaces the Procedure typedef (which only supported void functions) with
the Function typedef which supports return values, e.g.:

  Function<FooId, int32_t(std::string)> Foo;

The RPC primitives and channel operations are also expanded. RPC channels must
support four new operations: startSendMessage, endSendMessage,
startRecieveMessage and endRecieveMessage, to handle channel locking. In
addition, serialization support for tuples to RPCChannels is added to enable
multiple return values.

The RPC primitives are expanded from callAppend, call, expect and handle, to:

appendCallAsync - Make an asynchronous call to the given function.

callAsync - The same as appendCallAsync, but calls send on the channel when
            done.

callSTHandling - Blocking call for single-threaded code. Wraps a call to
                 callAsync then waits on the result, using a user-supplied
                 handler to handle any callbacks from the remote.

callST - The same as callSTHandling, except that it doesn't handle
         callbacks - it expects the result to be the first return.

expect and handle - as before.

handleResponse - Handle a response from the remote.

waitForResult - Wait for the response with the given sequence number to arrive.

llvm-svn: 266581
2016-04-18 01:06:49 +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
Kevin Enderby 8fb96b958a More more change need as part of r264187 where ErrorOr<> was added
to getSymbolType().

llvm-svn: 264194
2016-03-23 21:20:16 +00:00
Kevin Enderby 5afbc1cda7 Fix a crash in running llvm-objdump -t with an invalid Mach-O file already
in the test suite. While this is not really an interesting tool and option to run
on a Mach-O file to show the symbol table in a generic libObject format
it shouldn’t crash.

The reason for the crash was in MachOObjectFile::getSymbolType() when it was
calling MachOObjectFile::getSymbolSection() without checking its return value
for the error case.

What makes this fix require a fair bit of diffs is that the method getSymbolType() is
in the class ObjectFile defined without an ErrorOr<> so I needed to add that all
the sub classes.  And all of the uses needed to be updated and the return value
needed to be checked for the error case.

The MachOObjectFile version of getSymbolType() “can” get an error in trying to
come up with the libObject’s internal SymbolRef::Type when the Mach-O symbol
symbol type is an N_SECT type because the code is trying to select from the
SymbolRef::ST_Data or SymbolRef::ST_Function values for the SymbolRef::Type.
And it needs the Mach-O section to use isData() and isBSS to determine if
it will return SymbolRef::ST_Data.

One other possible fix I considered is to simply return SymbolRef::ST_Other
when MachOObjectFile::getSymbolSection() returned an error.  But since in
the past when I did such changes that “ate an error in the libObject code” I
was asked instead to push the error out of the libObject code I chose not
to implement the fix this way.

As currently written both the COFF and ELF versions of getSymbolType()
can’t get an error.  But if isReservedSectionNumber() wanted to check for
the two known negative values rather than allowing all negative values or
the code wanted to add the same check as in getSymbolAddress() to use
getSection() and check for the error then these versions of getSymbolType()
could return errors.

At the end of the day the error printed now is the generic “Invalid data was
encountered while parsing the file” for object_error::parse_failed.  In the
future when we thread Lang’s new TypedError for recoverable error handling
though libObject this will improve.  And where the added // Diagnostic(…
comment is, it would be changed to produce and error message
like “bad section index (42) for symbol at index 8” for this case.

llvm-svn: 264187
2016-03-23 20:27:00 +00:00
Saleem Abdulrasool fa8c6ed3fa ExecutionEngine: tweak debug log
Add a newline to separate the log message.  NFC.

llvm-svn: 262777
2016-03-05 20:00:41 +00:00
Lang Hames 3b514554a2 [RuntimeDyld] Fix '_' stripping in RTDyldMemoryManager::getSymbolAddressInProcess.
The RTDyldMemoryManager::getSymbolAddressInProcess method accepts a
linker-mangled symbol name, but it calls through to dlsym to do the lookup (via
DynamicLibrary::SearchForAddressOfSymbol), and dlsym expects an unmangled
symbol name.

Historically we've attempted to "demangle" by removing leading '_'s on all
platforms, and fallen back to an extra search if that failed. That's broken, as
it can cause symbols to resolve incorrectly on platforms that don't do mangling
if you query '_foo' and the process also happens to contain a 'foo'.

Fix this by demangling conditionally based on the host platform. That's safe
here because this function is specifically for symbols in the host process, so
the usual cross-process JIT looking concerns don't apply.

M    unittests/ExecutionEngine/ExecutionEngineTest.cpp
M    lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp

llvm-svn: 262657
2016-03-03 21:23:15 +00:00
Rafael Espindola 5cd721ae12 Refactor duplicated code for linking with pthread.
llvm-svn: 262344
2016-03-01 15:54:40 +00:00
Lang Hames e1fd99c197 [Orc] Add stack-realignment code to the i386 resolver function.
The resolver uses the fxsave/fxrstor instructions, which require 16-byte
alignment, to save SSE state to the stack. Since 16-byte alignment can't be
assumed on all OSes (and all i386 OSes share this function) - add code to
automatically bump the alignment to 16-bytes on entry to the function.

llvm-svn: 261503
2016-02-21 22:50:26 +00:00
Andrew Kaylor b68464eb78 Fix build LLVM with -D LLVM_USE_INTEL_JITEVENTS:BOOL=ON on Windows
Differential Revision: http://reviews.llvm.org/D16940

llvm-svn: 261033
2016-02-16 23:52:18 +00:00
Duncan P. N. Exon Smith 3f7f883e06 Support: Fix incremental build when re-configuring targets
r180893 added an indirect include of llvm/Config/Targets.def to
llvm/Support/CodeGen.h, which in turn is included by things like
llvm/IR/Module.h.  After a full build of LLVM and Clang, ninja had to
rebuild 1274 files after reconfiguring.

This commit strips CodeGen.h back down to just a pile of enums and moves
the expensive includes over to CodeGenCWrappers.h (which is only
included in two places).  This gets ninja down to 88 files if you
reconfigure with, e.g., -DLLVM_TARGETS_TO_BUILD=X86.

llvm-svn: 260835
2016-02-13 22:58:43 +00:00
Lang Hames 4f8194e81d [Orc] Add lazy-JITting support for i386.
This patch adds a new class, OrcI386, which contains the hooks needed to
support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT
re-entry code uses the FXSAVE/FXRSTOR instructions).

Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and
regression and unit tests are enabled for this architecture.

llvm-svn: 260338
2016-02-10 01:02:33 +00:00
Lang Hames 120a9b418b [Orc] Slightly improve the x86-64 resolver block machine code.
Replace leaq + movq of a pointer with a single movabsq.

llvm-svn: 259968
2016-02-06 00:55:08 +00:00
Lang Hames d677fa8332 [Orc] Fix a typo in the comments for the x86_64 resolver block.
llvm-svn: 259953
2016-02-05 23:27:48 +00:00
Lang Hames e28b118be0 [Orc] Turn OrcX86_64::IndirectStubsInfo into a template helper class:
GenericIndirectStubsInfo.

This will allow architecture support classes for other architectures to re-use
this code.

llvm-svn: 259549
2016-02-02 19:31:15 +00:00
Lang Hames 2d8a2aa60a [RuntimeDyld][MachO] Fix handling of empty eh-frame sections.
This patch switches from an unguarded to a guarded loop for eh-frame record
fixups. In the unguarded version we would always make at least one call to
processFDE, which would then crash trying to fix up a frame that didn't exist.

Fixes <rdar://problem/24301582>

llvm-svn: 259103
2016-01-28 22:35:48 +00:00
Chris Bieneman e49730d4ba Remove autoconf support
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html

"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi

Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark

Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits

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

llvm-svn: 258861
2016-01-26 21:29:08 +00:00
Benjamin Kramer f57c1977c1 Reflect the MC/MCDisassembler split on the include/ level.
No functional change, just moving code around.

llvm-svn: 258818
2016-01-26 16:44:37 +00:00
Lang Hames 3db630b5e7 [RuntimeDyld][AArch64] Add support for the MachO ARM64_RELOC_SUBTRACTOR reloc.
llvm-svn: 258438
2016-01-21 21:59:50 +00:00
David Blaikie 8ecf9938b2 Orc: Simplify lambda by using std::set's initializer_list ctor
llvm-svn: 258359
2016-01-20 22:24:26 +00:00
Evgeniy Stepanov b640415f9b Fix build warning.
error: field 'CCMgr' will be initialized after field 'IndirectStubsMgr' [-Werror,-Wreorder]
    : DL(TM.createDataLayout()), CCMgr(std::move(CCMgr)),

llvm-svn: 258354
2016-01-20 22:02:07 +00:00
Lang Hames 6c3e790e78 [Orc] Fix a use-after-move bug in the Orc C-bindings stack.
llvm-svn: 258324
2016-01-20 17:39:52 +00:00
Lang Hames 00b7bef269 [Orc] #undef a MACRO after I'm done with it.
Suggested by Philip Reames in review of r257951.

Thanks Philip!

llvm-svn: 258203
2016-01-19 22:20:21 +00:00
Lang Hames 2fe7acb773 [Orc] Refactor ObjectLinkingLayer::addObjectSet to defer loading objects until
they're needed.

Prior to this patch objects were loaded (via RuntimeDyld::loadObject) when they
were added to the ObjectLinkingLayer, but were not relocated and finalized until
a symbol address was requested. In the interim, another object could be loaded
and finalized with the same memory manager, causing relocation/finalization of
the first object to fail (as the first finalization call may have marked the
allocated memory for the first object read-only).

By deferring the loadObject call (and subsequent memory allocations) until an
object file is needed we can avoid prematurely finalizing memory.

llvm-svn: 258185
2016-01-19 21:06:38 +00:00
Manuel Jacob 5f6eaac611 GlobalValue: use getValueType() instead of getType()->getPointerElementType().
Reviewers: mjacob

Subscribers: jholewinski, arsenm, dsanders, dblaikie

Patch by Eduard Burtescu.

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

llvm-svn: 257999
2016-01-16 20:30:46 +00:00
Lang Hames c715ebbb99 [Orc] Replace switch cases with a macro.
The cases of this switch are all perfectly regular (except for the first case).
A macro is more readable here.

Thanks to Dave Blaikie for the suggestion. 

llvm-svn: 257951
2016-01-15 23:19:06 +00:00
Amaury Sechet 74f4ce6193 LLVMRunStaticConstructors can be called before object is finalized,
Summary: Since you cannot call finalizeObject manually through the C-API and other functions from the C-API automatically call it, LLVMRunStaticConstructors should also call it or otherwise you cannot call it without first calling a workaround function (or call any other function from the C-API which implicitly finalizes the object).

Reviewers: dnovillo, spatel, bkramer, deadalnix, joker.eph, echristo, lhames

Subscribers: llvm-commits

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

llvm-svn: 257849
2016-01-15 00:23:34 +00:00
Lang Hames 52c4724165 [Orc] Add support for EH-frame registration to the Orc Remote Target utility
classes.

OrcRemoteTargetClient::RCMemoryManager will now register EH frames with the
server automatically. This allows remote-execution of code that uses exceptions.

llvm-svn: 257816
2016-01-14 22:02:03 +00:00
Rui Ueyama da00f2fdf4 Update to use new name alignTo().
llvm-svn: 257804
2016-01-14 21:06:47 +00:00
Lang Hames 9d7a269f47 [LLI] Replace the LLI remote-JIT support with the new ORC remote-JIT components.
The new ORC remote-JITing support provides a superset of the old code's
functionality, so we can replace the old stuff. As a bonus, a couple of
previously XFAILed tests have started passing.

llvm-svn: 257343
2016-01-11 16:35:55 +00:00
Lang Hames 4d0a5a9ec6 [Orc] Add support for remote JITing to the ORC API.
This patch adds utilities to ORC for managing a remote JIT target. It consists
of:

1. A very primitive RPC system for making calls over a byte-stream.  See
RPCChannel.h, RPCUtils.h.

2. An RPC API defined in the above system for managing memory, looking up
symbols, creating stubs, etc. on a remote target. See OrcRemoteTargetRPCAPI.h.

3. An interface for creating high-level JIT components (memory managers,
callback managers, stub managers, etc.) that operate over the RPC API. See
OrcRemoteTargetClient.h.

4. A helper class for building servers that can handle the RPC calls. See
OrcRemoteTargetServer.h.

The system is designed to work neatly with the existing ORC components and
functionality. In particular, the ORC callback API (and consequently the
CompileOnDemandLayer) is supported, enabling lazy compilation of remote code.

Assuming this doesn't trigger any builder failures, a follow-up patch will be
committed which tests these utilities by using them to replace LLI's existing
remote-JITing demo code.

llvm-svn: 257305
2016-01-11 01:40:11 +00:00
Lang Hames 70b2406f78 [Orc] Rename OrcTargetSupport to OrcArchitectureSupport to avoid confusion with
the upcoming remote-target support classes.

llvm-svn: 257302
2016-01-11 00:56:15 +00:00
Lang Hames 4026f90e5d [Orc] Add error codes and a new std::error_category for remote-jit errors.
These will be used by an upcoming patch that adds remote-jit support utilities
to ORC.

llvm-svn: 257297
2016-01-11 00:34:13 +00:00
Lang Hames b0934294b2 [RuntimeDyld] Add a notifyObjectLoaded method to RuntimeDyld::MemoryManager.
This is a more generic version of the MCJITMemoryManager::notifyObjectLoaded
method: It provides only a RuntimeDyld reference (rather than an
ExecutionEngine), and so can be used with ORC JIT stacks.

llvm-svn: 257296
2016-01-10 23:59:41 +00:00