Support for ELF::R_ARM_THM_MOVW_PREL_NC and ELF::R_ARM_THM_MOVT_PREL
is added. Move instructions with PC-relative immediates can be handled
in Thumb mode with this addition.
The system linker merges __objc_imageinfo flags values to select a
compatible set of flags using the minimum swift version and only
erroring on incompatible ABIs. Match that behaviour in the orc macho
platform. One wrinkle is that the JIT can add new objects after the
dylib is running code. In that case we only check for known incompatible
flags and ignore the swift version. It's too late to change the flags at
that point and swift version is unlikely to change runtime behaviour in
practice.
The pass only requires that it can determine a uniquely identified
target at some offsets. Multiple relocations at the same offset are fine
otherwise and will be required when adding exception handling support
for RISC-V.
These files satisfy all of the following:
- misc-include-cleaner indicates that these files do not need
Endian.h.
- They do not mention "endian" anywhere.
- They do not include any *.inc or *.def, which could need
llvm::support::endian.
Currently, the interpreter does not initialize `undef` constants of
aggregate types correctly (with respect to arrays).
The initialization of the array elements is skipped although it is valid
to directly write to them. Instructions like
`insertvalue {i32, [4 x i32]} undef, i32 1, 1, 2` therefore lead to a
crash.
This is fixed by initializing array values just as fixed-size vectors or
structs.
Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class. This patch replaces
{big,little,native} with llvm::endianness::{big,little,native}.
This patch completes the migration to llvm::endianness and
llvm::endianness::{big,little,native}. I'll post a separate patch to
remove the migration helpers in llvm/Support/Endian.h:
using endianness = llvm::endianness;
constexpr llvm::endianness big = llvm::endianness::big;
constexpr llvm::endianness little = llvm::endianness::little;
constexpr llvm::endianness native = llvm::endianness::native;
Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form. This patch replaces
support::endianness with llvm::endianness.
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form. This patch replaces
support::endianness::{big,little,native} with
llvm::endianness::{big,little,native}.
This restores the pre-b9383a86b8f behavior. Most platforms / compilers don't
add relocations for CIEs, however they're not prohibited and we want objects
that contain them to remain loadable.
system_endianness() just returns llvm::endianness::native, a
compile-time constant equivalent to std::native in C++20. This patch
deprecates system_endianness() while replacing all invocations of
system_endianness() with llvm::endianness::native.
While we are at it, this patch replaces
llvm::support::endianness::{big,little} with
llvm::endianness::{big,little} in those statements that happen to call
system_endianness(). It does not go out of its way to replace other
occurrences of llvm::support::endianness::{big,little}.
* Remove unused variable.
* Error on existing edge at CIE pointer field.
* Simplify CFI processing in `EHFrameEdgeFixer`: The code expects
`DWARFRecordSectionSplitter` to split each CFI record into its own
block, so remove loop over possibly multiple entries in one block.
We should eventually migrate llvm::support::endianness to std::endian
when C++20 is available for the codebase.
This patch prepares our codebase for that future by removing the
assumption that native is a unique value different from both big and
little. Note that in C++20, native is equal to either big or little
on typical machines, where the endianness is the same for all scalar
types.
Without this patch, we pass G.getEndianness() as one of the parameters
to DWARFContext::create. The problem is that G.getEndianness() is of:
enum endianness {big, little, native};
whereas DWARFContext::create is expecting "bool isLittleEndian". That
is, we are relying on an implicit conversion to convert big and little
to false and true, respectively.
When we migrate llvm::support::endianness to std::endian in future, we
can no longer rely on an implicit conversion because std::endian is
declared with "enum class". Even if we could, the conversion would
not be guaranteed to work because, for example, libcxx defines:
enum class endian {
little = 0xDEAD,
big = 0xFACE,
:
where big and little are not boolean values.
This patch fixes the problem by properly converting G.getEndianness()
to a boolean value.
At line 191, `addSymbol` takes the name by reference but does not make
an internal copy to the string, meaning the local
`optional<std::string>` would get freed and leave Orc with a dangling
pointer. Fix this by just using an `optional<StringRef>` instead.
Instead of ConstantExpr::getCast() with a fixed opcode, use the
corresponding getXYZ methods instead. For the one place creating
a pointer bitcast drop it entirely, as this is redundant with
opaque pointers.
This re-applies db51e572893, which was reverted in 05b1a2cb3e6 due to bot
failures. The DebuggerSupportPlugin now depends on DWARF, so it has been moved
to the new OrcDebugging library (as has the enableDebuggerSupport API).
This patch adds line numbers to perf jitdump records emitted by the
PerfSupportPlugin, by parsing and using a DWARFContext from preserved debug
sections.
To avoid making the OrcJIT library depend on DebugInfoDWARF this patch
introduces a new OrcDebugging library.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D146391
The *Policy suffix came from the earlier MemAllocPolicy type, where it was
included to distinguish the type from a memory-allocation operation.
MemLifetime is a noun already, so the *Policy suffix is just dead weight now.
This re-applies e1a5bb59b91, which was reverted in e5f169f91a8 due to LSan
failures on some bots (see https://github.com/llvm/llvm-project/issues/67586).
The LSan failures were not caused by this patch (just exposed by it), so LSan
was disabled for the failing test in 47625fea5e3. This should be safe to
re-land now.
This change means that debugger support only needs to be linked in if it's
used. The code size of debugger support is expected to increase as we improve
it (e.g. pulling in DWARF parsing), so making it an optional extra is useful
for controlling final binary sizes.
This function will be run prior to platform setup to provide LLJIT clients with
a chance to customize the LLJIT instance (e.g. install plugins) before the JIT
runtime is loaded.
The motivating use-case is debugger support: We want to install the debugger
plugin before the runtime is loaded (during platform setup) so that the runtime
itself can be debugged. A patch to do this will be committed shortly.
No testcase: This code generates an in-memory object file that is shared with
the debugger. The object file is malformed in ways that don't matter to the
debugger, but mean that it can't be inspected by most tools.
Add pointer write functionality to MemoryAccess that is needed for implementing redirection manager. It also refactors the code a bit by introducing InProcessMemoryAccess class.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D157378
/data/llvm-project/llvm/lib/ExecutionEngine/Orc/TargetProcess/JITLoaderPerf.cpp:118:10: error: variable 'Written' set but not used [-Werror,-Wunused-but-set-variable]
size_t Written = 0;
^
1 error generated.
This patch ports PerfJITEventListener to a JITLink plugin, but adds unwind
record support and drops debuginfo support temporarily. Debuginfo can be
enabled in the future by providing a way to obtain a DWARFContext from a
LinkGraph.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D146169
JITLink for ppc64 has implemented all relocations implemented in rtdyld for ppc64 and has passed all existed lit tests and unittests in llvm/clang/compiler-rt. I propose making JITLink for ppc64 default in LLJIT.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D159175
Add support for static Arm relocations of R_ARM_MOVT_ABS and R_ARM_MOVW_ABS_NC
which are emitted by movt and movw instructions. The implementation contains
relocation fixup and its testing as well as its encode/decode functions for
reading and writing immediate values together with its unittests.
This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future change to the params of
TargetMachine.
This matches other nearby enums.
For downstream users, this should be a fairly straightforward
replacement,
e.g. s/CodeGenOpt::Aggressive/CodeGenOptLevel::Aggressive
or s/CGFT_/CodeGenFileType::
There is case that R_PPC64_REL24 with non-zero addend. The assertion is incorrectly triggered in such situation.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D158708
We don't have to set or clear the Thumb bit in relocation fixup values.
It's not part of the branch range and the respective encoding functions
like encodeImmBT4BlT1BlxT2() shift out the least significant bit anyway.
This was a leftover from the initial patch before we switched to store
Thumb state in target-flags with D146641.
