Summary: When the MCJIT generates ELF code, some DWARF data requires 64-bit PC-relative relocation (R_390_PC64). This patch adds support for R_390_PC64 relocation to RuntimeDyld::resolveSystemZRelocation, to avoid an assertion failure.
Reviewers: uweigand
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D20033
llvm-svn: 269436
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
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
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
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
r253918 had refactored expressions like "A - B.Address + C" to "A -
B.getAddressWithOffset(C)". This is incorrect, since the latter really
computes "A - B.Address - C".
None of the tests I can run locally on x86 broke due to this bug, but it
is the current suspect for breakage on the AArch64 buildbots.
llvm-svn: 254017
Summary:
For relocation types that are known to not require stub functions, there
is no need to allocate extra space for the stub functions.
Reviewers: lhames, reames, maksfb
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14676
llvm-svn: 253920
Summary:
Change SectionEntry to keep track of the size of its underlying
allocation, and use that to bounds check advanceStubOffset.
Reviewers: lhames, andrew.w.kaylor, reames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14675
llvm-svn: 253919
Summary:
Remove naked access to the data members in `SectionEntry` and route
accesses through accessor functions. This makes it obvious how the
instances of the class are used, and will also facilitate adding bounds
checking to `advanceStubOffset` in a later change.
Reviewers: lhames, loladiro, andrew.w.kaylor
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14674
llvm-svn: 253918
When resolving R_PPC64_REL24, code used to check for an address delta
that fits in 24 bits, while the instructions that take this relocation
actually can process address deltas that fit into *26* bits (as those
instructions have a 24 bit field, but implicitly append two zero bits
at the end since all instruction addresses are a multiple of 4).
This means that code would signal overflow once a single object's text
section exceeds 8 MB, while we can actually support up to 32 MB.
Partially fixes PR25540.
llvm-svn: 253369
This patch adds a test for MIPS64R6 relocations, it corrects check
expressions for R_MIPS_26 and R_MIPS_PC16 relocations in MIPS64R2 test, and
it adds run for big endian in MIPS64R2 test.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D11217
llvm-svn: 246311
Previously, for O32 ABI we did not calculate correct addend for R_MIPS_HI16
and R_MIPS_PCHI16 relocations. This patch fixes that.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D11186
llvm-svn: 244897
LoadedObjectInfo was depending on the implicit copy ctor in the presence
of a user-declared dtor. Default (and protect) it in the base class and
make the devired classes final to avoid any risk of a public API that
would enable slicing.
llvm-svn: 244112
Add support for resolving MIPS32r6 relocations in MCJIT.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D10687
llvm-svn: 241442
This function can really fail since the string table offset can be out of
bounds.
Using ErrorOr makes sure the error is checked.
Hopefully a lot of the boilerplate code in tools/* can go away once we have
a diagnostic manager in Object.
llvm-svn: 241297
Realistically, this will be returning ErrorOr for some time as refactoring the
user code to check once per section will take some time.
Given that, use it for checking if a relocation has addend or not.
While at it, add ELFRelocationRef to simplify the users.
llvm-svn: 241028
This is still a really odd function. Most calls are in object format specific
contexts and should probably be replaced with a more direct query, but at least
now this is not too obnoxious to use.
llvm-svn: 240777
So far, LLVM has not emitted correct addend for N64 and N32 ABI. This patch
fixes that. It also removes fixup from MCJIT for R_MIPS_PC16 relocation.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D10565
llvm-svn: 240404
This patch changes getRelocationAddend to use ErrorOr and considers it an error
to try to get the addend of a REL section.
If, for example, a x86_64 file has a REL section, that file is corrupted and
we should reject it.
Using ErrorOr is not ideal since we check the section type once per relocation
instead of once per section.
Checking once per section would involve getRelocationAddend just asserting and
callers checking the section before iterating over the relocations.
In any case, this is an improvement and includes a test.
llvm-svn: 240176
fix segfault by checking for UnknownArch, since
getArchTypePrefix() will return nullptr for UnknownArch.
This fixes regression caused by r238424.
llvm-svn: 239456
This patch adds R_MIPS_PC32 relocation for Mips64.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D10235
llvm-svn: 239301
The windows buildbot originally failed because the check expressions are
evaluated as 64-bit values, even for 32-bit symbols. Fixed this by comparing
bottom 32-bits of the expressions.
The host/target endian mismatch issue is that it's invalid to read/write target
values using a host pointer without taking care of endian differences between
the target and host. Most (if not all) instances of
reinterpret_cast<uint32_t*>() in the RuntimeDyld are examples of this bug.
This has been fixed for Mips using the endian aware read/write functions.
The original commits were:
r238838:
[mips] Add RuntimeDyld tests for currently supported O32 relocations.
Reviewers: petarj, vkalintiris
Reviewed By: vkalintiris
Subscribers: vkalintiris, llvm-commits
Differential Revision: http://reviews.llvm.org/D10126
r238844:
[mips][mcjit] Add support for R_MIPS_PC32.
Summary:
This allows us to resolve relocations for DW_EH_PE_pcrel TType encodings
in the exception handling LSDA.
Also fixed a nearby typo.
Reviewers: petarj, vkalintiris
Reviewed By: vkalintiris
Subscribers: vkalintiris, llvm-commits
Differential Revision: http://reviews.llvm.org/D10127
llvm-svn: 238915
Summary:
This allows us to resolve relocations for DW_EH_PE_pcrel TType encodings
in the exception handling LSDA.
Also fixed a nearby typo.
Reviewers: petarj, vkalintiris
Reviewed By: vkalintiris
Subscribers: vkalintiris, llvm-commits
Differential Revision: http://reviews.llvm.org/D10127
llvm-svn: 238844
Add support for resolving MIPS64r2 and MIPS64r6 relocations in MCJIT.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D9667
llvm-svn: 238424
Summary:
This supersedes http://reviews.llvm.org/D4010, hopefully properly
dealing with the JIT case and also adds an actual test case.
DwarfContext was basically already usable for the JIT (and back when
we were overwriting ELF files it actually worked out of the box by
accident), but in order to resolve relocations correctly it needs
to know the load address of the section.
Rather than trying to get this out of the ObjectFile or requiring
the user to create a new ObjectFile just to get some debug info,
this adds the capability to pass in that info directly.
As part of this I separated out part of the LoadedObjectInfo struct
from RuntimeDyld, since it is now required at a higher layer.
Reviewers: lhames, echristo
Reviewed By: echristo
Subscribers: vtjnash, friss, rafael, llvm-commits
Differential Revision: http://reviews.llvm.org/D6961
llvm-svn: 237961
isInt is a little easier to read, let's use that more consistently.
Incidentally, this also silences a warning for shifting a negative
number.
This fixes PR23532.
llvm-svn: 237476
This reapplies r235060 and 235070, which were reverted because of test failures
in LLDB. The failure was caused because at moment RuntimeDyld is processing
relocations for all sections, irrespective of whether we actually load them
into memory or not, but RuntimeDyld was not actually remembering where in memory
the unrelocated section is. This commit includes a fix for that issue by
remembering that pointer, though the longer term fix should be to stop processing
unneeded sections.
Original Summary:
This allows us to get rid of the original unrelocated object file after
we're done processing relocations (but before applying them).
MachO and COFF already do not require this (currently we have temporary hacks
to prevent ownership from being released, but those are brittle and should be
removed soon).
The placeholder mechanism allowed the relocation resolver to look at original
object file to obtain more information that are required to apply the
relocations. This is usually necessary in two cases:
- For relocations targetting sub-word memory locations, there may be pieces
of the instruction at the target address which we should not override.
- Some relocations on some platforms allow an extra addend to be encoded in
their immediate fields.
The problem is that in the second case the information cannot be recovered
after the relocations have been applied once because they will have been
overridden. In the first case we also need to be careful to not use any bits
that aren't fixed and may have been overriden by applying a first relocation.
In the past both have been fixed by just looking at original object file. This
patch attempts to recover the information from the first by looking at the
relocated object file, while the extra addend in the second case is read
upon relocation processing and addend to the regular addend.
I have tested this on X86. Other platforms represent my best understanding
of how those relocations should work, but I may have missed something because
I do not have access to those platforms.
We will keep the ugly workarounds in place for a couple of days, so this commit
can be reverted if it breaks the bots.
Differential Revision: http://reviews.llvm.org/D9028
llvm-svn: 236341
Bryan Chan