Some background: One can pass compiled resource files (.res files) directly
to the linker on Windows. If a resource file is given, the linker will run
"cvtres" command in background to convert the resource file to a COFF file
to link it.
What I'm trying to do with this patch is to make the linker to recognize
the resource file by file magic, so that it can run cvtres command.
Differential Revision: http://llvm-reviews.chandlerc.com/D1943
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192742 91177308-0d34-0410-b5e6-96231b3b80d8
It's useful for the memory managers that are allocating a section to know what the name of the section is.
At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what
memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about
what each allocation is for. This allows clients that supply their own memory managers to do this.
Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM
client.
This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM. I'm assuming that
it's safe to change the C++ API because that API is allowed to change. I'm assuming that it's safe to change
the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory
management C API).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191804 91177308-0d34-0410-b5e6-96231b3b80d8
Tests to follow.
PIC with small code model and EH frame handling will not work with multiple modules. There are also some rough edges to be smoothed out for remote target support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191722 91177308-0d34-0410-b5e6-96231b3b80d8
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The LLVM portions of this patch simply add ppc64le coverage everywhere
that ppc64 coverage currently exists. There is nothing of any import
worth testing until such time as little-endian code generation is
implemented. In the corresponding Clang patch, there is a new test
case variant to ensure that correct built-in defines for little-endian
code are generated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187179 91177308-0d34-0410-b5e6-96231b3b80d8
For COFF and MachO, sections semantically have relocations that apply to them.
That is not the case on ELF.
In relocatable objects (.o), a section with relocations in ELF has offsets to
another section where the relocations should be applied.
In dynamic objects and executables, relocations don't have an offset, they have
a virtual address. The section sh_info may or may not point to another section,
but that is not actually used for resolving the relocations.
This patch exposes that in the ObjectFile API. It has the following advantages:
* Most (all?) clients can handle this more efficiently. They will normally walk
all relocations, so doing an effort to iterate in a particular order doesn't
save time.
* llvm-readobj now prints relocations in the same way the native readelf does.
* probably most important, relocations that don't point to any section are now
visible. This is the case of relocations in the rela.dyn section. See the
updated relocation-executable.test for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182908 91177308-0d34-0410-b5e6-96231b3b80d8
libExecutionEngine. Move method implementations that aren't specific to
allocation out of SectionMemoryManager and into RTDyldMemoryManager.
This is in preparation for exposing RTDyldMemoryManager through the C
API.
This is a fixed version of r182407 and r182411. That first revision
broke builds because I forgot to move the conditional includes of
various POSIX headers from SectionMemoryManager into
RTDyldMemoryManager. Those includes are necessary because of how
getPointerToNamedFunction works around the glibc libc_nonshared.a thing.
The latter revision still broke things because I forgot to include
llvm/Config/config.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182418 91177308-0d34-0410-b5e6-96231b3b80d8
libExecutionEngine. Move method implementations that aren't specific to
allocation out of SectionMemoryManager and into RTDyldMemoryManager.
This is in preparation for exposing RTDyldMemoryManager through the C
API.
This is a fixed version of r182407. That revision broke builds because I
forgot to move the conditional includes of various POSIX headers from
SectionMemoryManager into RTDyldMemoryManager. Those includes are
necessary because of how getPointerToNamedFunction works around the
glibc libc_nonshared.a thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182411 91177308-0d34-0410-b5e6-96231b3b80d8
libExecutionEngine. Move method implementations that aren't specific to
allocation out of SectionMemoryManager and into RTDyldMemoryManager.
This is in preparation for exposing RTDyldMemoryManager through the C
API.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182407 91177308-0d34-0410-b5e6-96231b3b80d8
This gets exception handling working on ELF and Macho (x86-64 at least).
Other than the EH frame registration, this patch also implements support
for GOT relocations which are used to locate the personality function on
MachO.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181167 91177308-0d34-0410-b5e6-96231b3b80d8
As with global accesses, external functions could exist anywhere in
memory. Therefore the stub must create a complete 64-bit address. This
patch implements the fragment as (roughly):
movz x16, #:abs_g3:somefunc
movk x16, #:abs_g2_nc:somefunc
movk x16, #:abs_g1_nc:somefunc
movk x16, #:abs_g0_nc:somefunc
br x16
In principle we could save 4 bytes by using a literal-load instead,
but it is unclear that would be more efficient and can only be tested
when real hardware is readily available.
This allows (for example) the MCJIT test 2003-05-07-ArgumentTest to
pass on AArch64.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181133 91177308-0d34-0410-b5e6-96231b3b80d8
Another step towards reinstating the SystemZ backend. I'll commit
the configure changes separately (TARGET_HAS_JIT etc.), then commit
a patch to enable the MCJIT tests on SystemZ.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181015 91177308-0d34-0410-b5e6-96231b3b80d8
For regular object files this is only meaningful for common symbols. An object
file format with direct support for atoms should be able to provide alignment
information for all symbols.
This replaces getCommonSymbolAlignment and fixes
test-common-symbols-alignment.ll on darwin. This also includes a fix to
MachOObjectFile::getSymbolFlags. It was marking undefined symbols as common
(already tested by existing mcjit tests now that it is used).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180736 91177308-0d34-0410-b5e6-96231b3b80d8
For MachO we need information that is not represented in ObjRelocationInfo.
Instead of copying the bits we think are needed from a relocation_iterator,
just pass the relocation_iterator down to the format specific functions.
No functionality change yet as we still drop the information once
processRelocationRef returns.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180711 91177308-0d34-0410-b5e6-96231b3b80d8
This small change adds support for that. It will make all MCJIT tests pass
in make-check on BigEndian platforms.
Patch by Petar Jovanovic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169178 91177308-0d34-0410-b5e6-96231b3b80d8
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
all symbols during object loading, not just global ones.
This fixes JIT execution of code using llvm.global_ctors with internal
linkage constructors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168148 91177308-0d34-0410-b5e6-96231b3b80d8
Prior to this patch RuntimeDyld attempted to re-apply relocations every time reassignSectionAddress was called (via MCJIT::mapSectionAddress). In addition to being inefficient and redundant, this led to a problem when a section was temporarily moved too far away from another section with a relative relocation referencing the section being moved. To fix this, I'm adding a new method (finalizeObject) which the client can call to indicate that it is finished rearranging section addresses so the relocations can safely be applied.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167400 91177308-0d34-0410-b5e6-96231b3b80d8
Some ELF relocations require adding the a value to the original contents of the object buffer at the specified location. In order to properly handle multiple applications of a relocation, the RuntimeDyld code should be grabbing the original value from the object buffer and writing a new value into the loaded section buffer. This patch changes the parameters passed to resolveRelocations to accommodate this need.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167304 91177308-0d34-0410-b5e6-96231b3b80d8
Make sure to return a pointer into the target memory, not the local memory.
Often they are the same, but we can't assume that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163217 91177308-0d34-0410-b5e6-96231b3b80d8
No new tests are added.
All tests in ExecutionEngine/MCJIT that have been failing pass after this patch
is applied (when "make check" is done on a mips board).
Patch by Petar Jovanovic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162135 91177308-0d34-0410-b5e6-96231b3b80d8
- Improved parameter names for clarity
- Added comments
- emitCommonSymbols should return void because its return value is not being
used anywhere
- Attempt to reduce the usage of the RelocationValueRef type. Restricts it
for a single goal and may serve as a step for eventual removal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155908 91177308-0d34-0410-b5e6-96231b3b80d8
- There's no point having a different type for the local and global symbol
tables.
- Renamed SymbolTable to GlobalSymbolTable to clarify the intention
- Improved const correctness where relevant
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155898 91177308-0d34-0410-b5e6-96231b3b80d8
relocations are resolved. It's much more reasonable to do this decision when
relocations are just being added - we have all the information at that point.
Also a bit of renaming and extra comments to clarify extensions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155819 91177308-0d34-0410-b5e6-96231b3b80d8
- Add comments
- Change field names to be more reasonable
- Fix indentation and naming to conform to coding conventions
- Remove unnecessary includes / replace them by forward declatations
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155815 91177308-0d34-0410-b5e6-96231b3b80d8
