| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 194865
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Make identify_magic to recognize COFF import file.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2165
llvm-svn: 194852
|
|
|
|
|
|
| |
RuntimeDyldImpl::resolveExternalSymbols
llvm-svn: 194415
|
|
|
|
| |
llvm-svn: 193094
|
|
|
|
| |
llvm-svn: 193034
|
|
|
|
| |
llvm-svn: 192754
|
|
|
|
|
|
| |
Patch by Yaron Keren
llvm-svn: 192753
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 192742
|
|
|
|
| |
llvm-svn: 192737
|
|
|
|
| |
llvm-svn: 192732
|
|
|
|
| |
llvm-svn: 192504
|
|
|
|
|
|
| |
Patch by Ashok Thirumurthi
llvm-svn: 192020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APIs, both in C++ and C land.
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).
llvm-svn: 191804
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 191722
|
|
|
|
| |
llvm-svn: 189728
|
|
|
|
|
|
|
|
|
| |
Object/MachOFormat.h over to Support/MachO.h."
This reverts commits r189319 and r189315. r189315 broke some tests on what I
believe are big-endian platforms.
llvm-svn: 189321
|
|
|
|
| |
llvm-svn: 189315
|
|
|
|
| |
llvm-svn: 188778
|
|
|
|
| |
llvm-svn: 188726
|
|
|
|
| |
llvm-svn: 188697
|
|
|
|
|
|
|
|
|
| |
If an ELF relocation is pointed at an absolute address, it will have a symbol ID of zero.
RuntimeDyldELF::processRelocationRef was not previously handling this case, and was instead trying to handle it as a section-relative fixup.
I think this is the right fix here, but my elf-fu is poor on some of the more exotic platforms, so I'd appreciate it if anyone with greater knowledge could verify this.
llvm-svn: 188572
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
same way as X86_64_GOT relocations. The 'Load' part of GOTLoad is just an
optimization hint for the linker anyway, and can be safely ignored.
This patch also fixes some minor issues with the relocations introduced while
processing an X86_64_GOT[Load]: the addend for the GOT entry should always be
zero, and the addend for the replacement relocation at the original offset
should be the same as the addend of the relocation being replaced.
I haven't come up with a good way of testing this yet, but I'm working on it.
This fixes <rdar://problem/14651564>.
llvm-svn: 188499
|
|
|
|
|
|
|
|
| |
un-breaks simple use cases while I work on more general support.
<rdar://problem/14487667>
llvm-svn: 188044
|
|
|
|
|
|
|
|
| |
* ELFTypes.h contains template magic for defining types based on endianess, size, and alignment.
* ELFFile.h defines the ELFFile class which provides low level ELF specific access.
* ELFObjectFile.h contains ELFObjectFile which uses ELFFile to implement the ObjectFile interface.
llvm-svn: 188022
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 187179
|
|
|
|
|
|
|
| |
This should actually make the MCJIT tests pass again on AArch64. I don't know
how I missed their failure before.
llvm-svn: 187120
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to ARM change r182800, dynamic linker will read bits/addends from
the original object rather than from the object that might have been patched
previously. For the purpose of relocations for MCJIT stubs on MIPS, we
internally use otherwise unused MIPS relocations.
The change also enables MCJIT unit tests for MIPS (EL/BE), and the following
two tests now pass:
- MCJITTest.return_global and
- MCJITTest.multiple_functions.
These issues have been tracked as Bug 16250.
Patch by Petar Jovanovic.
llvm-svn: 187019
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the AArch64 ELF specification (4.6.8), it's the
assembler's responsibility to make sure the shift amount is correct in
relocated MOVZ/MOVK instructions.
This wasn't being obeyed by either the MCJIT CodeGen or RuntimeDyldELF
(which happened to work out well for JIT tests). This commit should
make us compliant in this area.
llvm-svn: 185360
|
|
|
|
| |
llvm-svn: 184191
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 183758
|
|
|
|
| |
llvm-svn: 183669
|
|
|
|
|
|
| |
Should fix the MCJIT tests on PPC.
llvm-svn: 183288
|
|
|
|
|
|
|
|
| |
In ELF (as in MachO), not all relocations point to symbols. Represent this
properly by using a symbol_iterator instead of a SymbolRef. Update llvm-readobj
ELF's dumper to handle relocatios without symbols.
llvm-svn: 183284
|
|
|
|
|
|
|
| |
This was missing from r182908. I didn't noticed it at the time because the MCJIT tests were
disabled when building with cmake on ppc64 (which I fixed in r183143).
llvm-svn: 183147
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 182908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would read-modify-write the target bits when processing
relocations for the MCJIT. This had the problem that when relocations
were processed multiple times for the same object file (as they can
be), the result is not idempotent and the values became corrupted.
The solution to this is to take any bits used in the destination from
the pristine object file as LLVM emitted it.
This should fix PR16013 and remote MCJIT on ARM ELF targets.
llvm-svn: 182800
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 182418
|
|
|
|
| |
llvm-svn: 182415
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 182411
|
|
|
|
| |
llvm-svn: 182409
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 182407
|
|
|
|
|
|
|
|
|
|
| |
AArch64 ELF uses .rela relocations so there's no need to actually make
use of the bits we're setting in the destination However, we should
make sure all bits are cleared properly since multiple runs of
resolveRelocations are possible and these could combine to produce
invalid results if stale versions remain in the code.
llvm-svn: 182214
|
|
|
|
|
|
|
|
| |
immediate fix
which doesn't resolve the deeper problem.
llvm-svn: 182098
|
|
|
|
|
|
|
| |
It was only implemented for ELF where it collected the Addend, so this
patch also renames it to getRelocationAddend.
llvm-svn: 181502
|
|
|
|
|
|
|
| |
This patch handles the R_PPC64_REL64 relocation type for powerpc64
for mcjit.
llvm-svn: 181220
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 181167
|
|
|
|
|
|
|
|
|
| |
This is about the simplest relocation, but surprisingly rare in actual
code.
It occurs in (for example) the MCJIT test test-ptr-reloc.ll.
llvm-svn: 181134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 181133
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The large memory model (default and main viable for JIT) emits
addresses in need of relocation as
movz x0, #:abs_g3:somewhere
movk x0, #:abs_g2_nc:somewhere
movk x0, #:abs_g1_nc:somewhere
movk x0, #:abs_g0_nc:somewhere
To support this we must implement those four relocations in the
dynamic loader.
This allows (for example) the test-global.ll MCJIT test to pass on
AArch64.
llvm-svn: 181132
|
|
|
|
|
|
|
|
|
|
|
| |
R_AARCH64_PCREL32 is present in even trivial .eh_frame sections and so
is required to compile any function without the "nounwind" attribute.
This change implements very basic infrastructure in the RuntimeDyldELF
file and allows (for example) the test-shift.ll MCJIT test to pass
on AArch64.
llvm-svn: 181131
|