We now check for:
1. Duplicate definitions of the same section name with different permissions.
2. Symbols whose size extends past the end of the containing block.
It's not clear to me whether either of these is strictly prohibited by the ELF
spec, but they seem pathalogical and JITLink doesn't currently handle them. For
now we'll make them recoverable errors so that if we do encounter these in the
wild we can report the issue(s).
The LinkGraph that is passed into the ELFJITLinker_x86_64 constructor is handed
off to the JITLinker base class, so can't be used in the constructor body. This
commit adds a getGraph method to JITLinker, and updates ELFJITLinker_x86_64 to
use that.
This allows JITLinkerBase implementations to check whether default passes
should be added. The ELF_x86_64 backend is updated to check this predicate
before installing the getOrCreateGOTSymbol pass.
This is an alternative solution to https://reviews.llvm.org/D158909.
By using bootstrap symbols to communicate these addresseses, rather than dlsym
lookups, we no longer need them to be exported from the main executable. On ELF,
where symbols aren't exported from the main executable by default, this
eliminates a common source of missing symbol errors and allows for smaller
executables (if exports from the main executable aren't otherwise needed and
can be removed).
For many interesting process-symbols setups we need access to the LLJIT instance
(e.g. to mangle symbols, or inspect the process triple). This patch updates the
ProcessSymbolsJITDylibSetupFunction to take an LLJIT reference and return the
process symbols JITDylib, which the callback must now create.
This reverts commit 4e3b89483a, with
fixes for places I'd missed updating in lld and lldb. I've also
renamed OptionVisibility::Default to "DefaultVis" to avoid ambiguity
since the undecorated name has to be available anywhere Options.inc is
included.
Original message follows:
This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and adds
variants of the OptTable APIs that use Visibility mask instead of
Include/Exclude flags.
We need to do this to clean up a bunch of complexity in the clang
driver's option handling - there's a whole slew of flags like
CoreOption, NoDriverOption, and FlangOnlyOption there today to try to
handle all of the permutations of flags that the various drivers need,
but it really doesn't scale well, as can be seen by things like the
somewhat recently introduced CLDXCOption.
Instead, we'll provide an additive model for visibility that's
separate from the other flags. For things like "HelpHidden", which is
used as a "subtractive" modifier for option visibility, we leave that
in "Flags" and handle it as a special case.
Note that we don't actually update the users of the Include/Exclude
APIs here or change the flags that exist in clang at all - that will
come in a follow up that refactors clang's Options.td to use the
increased flexibility this change allows.
Differential Revision: https://reviews.llvm.org/D157149
This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and adds
variants of the OptTable APIs that use Visibility mask instead of
Include/Exclude flags.
We need to do this to clean up a bunch of complexity in the clang
driver's option handling - there's a whole slew of flags like
CoreOption, NoDriverOption, and FlangOnlyOption there today to try to
handle all of the permutations of flags that the various drivers need,
but it really doesn't scale well, as can be seen by things like the
somewhat recently introduced CLDXCOption.
Instead, we'll provide an additive model for visibility that's
separate from the other flags. For things like "HelpHidden", which is
used as a "subtractive" modifier for option visibility, we leave that
in "Flags" and handle it as a special case.
Note that we don't actually update the users of the Include/Exclude
APIs here or change the flags that exist in clang at all - that will
come in a follow up that refactors clang's Options.td to use the
increased flexibility this change allows.
Differential Revision: https://reviews.llvm.org/D157149
RuntimeDyld has implemented more relocations than JITLink for ppc64. This patch adds relocations missing from JITLink for ppc64.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D157366
Creating stubs in JITLink require creating architecture-specific edges. In order to allow user to create stubs in cross-architecture manner, this patch exposes these stub creations functions by returning "stub creators" for given triple.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D155557
All command-line tools using `llvm::opt` create an enum of option IDs and a table of `OptTable::Info` object. Most of the tools use the same ID (`OPT_##ID`), kind (`Option::KIND##Class`), group ID (`OPT_##GROUP`) and alias ID (`OPT_##ALIAS`). This patch extracts that common code into canonical macros. This results in fewer changes when tweaking the `OPTION` macros emitted by the TableGen backend.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D157028
Since jitlink for ppc64le is ready for general use, test cases in compiler-rt for ELFNixPlatform support can be enabled.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D156399
Access to individual DefinitionGenerators is serialized in order to make
generators easier to implement: serializing access means that tryToGenerate
methods don't have to handle concurrent, potentially overlapping, requests.
Prior to this patch serialization was achieved by having each lookup acquire a
lock on each generator, however this causes the lookup thread to block if the
generator is in use. In the common case where many objects reference some
common library symbol that is provided by a generator this may cause many
threads to block concurrently preventing progress on other work.
This patch changes the model so that lookups are automatically suspended if
they need to use a generator that is already in use, and then automatically
resumed once the generator is free. This is achieved by reusing the lookup
suspension machinery that was introduced in 069919c9ba for optionally
asynchronous generators.
The ExecutionSession::removeJITDylibs operation will remove all JITDylibs in
the given list (i.e. first clear them, then remove them from the session).
ExecutionSession::endSession is updated to remove JITDylibs rather than just
clearing them. This prevents new code from being added to any JITDylib once
endSession has been called.
If JITLinkGeneric::linkPhase2 receives an Error rather than an InFlightAlloc
then we need to call JITLinkContext::notifyFailed, rather than calling
abandonAllocAndBailOut -- the latter asserts that there is an allocation to
abandon, and this was turning allocation errors into assertion failures in
debug mode.
This relocation type is often used for debug information on Windows. We
would previously abort due to the unreachable for the unhandled
relocation type. Add support for this to prevent LLDB from aborting if
it encounters this relocation type.
ELF object files can contain `.ctors` and `.dtors` sections that also
participate as initializers.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D154802
After PrePrunePass `claimOrExternalizeWeakAndCommonSymbols`, a defined symbol might become external. So determine a function call is external or not when building the linkgraph is not accurate. This largely affects updating TOC pointer on PowerPC. TOC pointer is supposed to be the same in one object file(if no mulitple TOC appears) and is updated when control flow transferred to another object file.
This patch defers checking a function call is external or not, in `buildTables_ELF_ppc64` which is a PostPrunePass.
This patch fixes failures when `jitlink -orc-runtime=/path/to/libort_rt.a` is used.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D155925
According to the ELFv2 ABI
> This relocation type is used to specify a function call where the TOC pointer is not initialized. It is similar to R_PPC64_REL24 in that it specifies a symbol to be resolved. If the symbol resolves to a function that requires a TOC pointer (as determined by st_other bits) then a link editor must arrange for the call to be via the global entry point of the called function. Any stub code must not rely on a valid TOC base address in r2.
This patch fixes handling of `R_PPC64_REL24_NOTOC` by using the same stub code sequence as lld.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D155672
An in-flight materialization may try to claim responsibility for new symbols
(via MaterializationResponsibility::defineMaterializing) after the tracker that
is associated with the materialization is removed, leaving the tracker defunct.
Failure to error out early here could leave the JITDylib in an invalid state,
with defineMaterializing associating new symbols with the already-defunct
tracker. Erroring out early prevents this.
Finalization of relaxation calls `finalizeBlockRelax` for every block in
the graph. This function, however, would iterate over //all// blocks in
the graph to remove `AlignRelaxable` edges. Since pointers to those
edges would still be stored in `RelaxEdges`, this caused a
use-after-free for graphs with multiple blocks.
This patch fixes this by only iterating over the edges of the current
block in `finalizeBlockRelax`.
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D154844
Renames TableManager's appendEntry method to registerPreExistingEntry and adds
a comment to explain its purpose. (TableManager subclasses are required to
implement a createEntry method which also appends entries to the map: this
rename aims to avoid any confusion between these methods)
In OrcAArch64::writeIndirectStubsBlock, masks the high bits of the immediate
operand to the stub's ldr instruction so that negative offsets to the stub
pointer do not overflow.
No testcase -- this fixes most of the OrcLazy testcases for AArch64 (at least on
Darwin), but we still need to fix the exception-handling test before we can turn
them on.
`JITLinkContext` is notified (using `notifyResolved`) of the final
symbol addresses after allocating memory and running the post-allocation
passes. However, linker relaxation, which can cause symbol addresses to
change, was run during the pre-fixup passes. This causes users of
JITLink (e.g., ORC) to pick-up wrong symbol addresses when linker
relaxation was enabled.
This patch fixes this by running relaxation during the post-allocation
passes.
Fixes#63671
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D154501
SectionMemoryManager's default memory mapper used to be a global static
object. If the SectionMemoryManager itself is a global static
object, it might be destroyed after its memory mapper and thus couldn't
use it from the destructor.
The Kaleidoscope tutorial reproduced this situation with MSVC for a long time.
Since 47f5c54f99 it's triggered with GCC as well. The solution from
this patch was proposed in the existing review https://reviews.llvm.org/D107087
before, but it didn't move forward.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D154338
D149522 introduced target features to LinkGraph. However, to avoid a
public dependency on MC, the features were stored in a std::vector
instead of using SubtargetFeatures directly.
Since SubtargetFeatures was moved from MC to TargetParser (D150549), we
can now use it directly to store the features. This patch implements
that and removes the (private) dependency on MC.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D153749
SubtargetFeature.h is currently part of MC while it doesn't depend on
anything in MC. Since some LLVM components might have the need to work
with target features without necessarily needing MC, it might be
worthwhile to move SubtargetFeature.h to a different location. This will
reduce the dependencies of said components.
Note that I choose TargetParser as the destination because that's where
Triple lives and SubtargetFeatures feels related to that.
This issues came up during a JITLink review (D149522). JITLink would
like to avoid a dependency on MC while still needing to store target
features.
Reviewed By: MaskRay, arsenm
Differential Revision: https://reviews.llvm.org/D150549
The relaxation algorithm used to only update offsets of relaxable edges.
This caused non-relaxable edges that appear after a relaxed instruction
to have an incorrect offset and be applied at the wrong location. This
patch fixes this by updating the offsets of all edges.
Note that this bug was caused by an incorrect translation of LLD's
relaxation algorithm. LLD always uses all edges during relaxation while
I decided to filter-out relaxable edges to prevent having to iterate
non-relaxable edges at each step. However, this had the side-effect of
only updating offsets of relaxable edges. This patch leaves the
filtering of relaxable edges as-is but iterates all edges when updating
offsets.
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D153515
This is useful for contexts where shouldAddDefaultTargetPasses returns
false but that still want to perform relaxation.
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D153538
Relaxable edges are created unconditionally, even when the relaxation
pass will not run. However, they were not recognized by applyFixup
causing them to not be applied.
To support configurations without the relaxation pass, this patch adds
these relaxable edges to applyFixup:
- CallRelaxable: Can be treated as R_RISCV_CALL
- AlignRelaxable: Can simply be ignored
An alternative could be to unconditionally run the relaxation pass, even
in contexts where shouldAddDefaultTargetPasses returns false. However, I
could imagine there being use cases for disabling relaxation which
wouldn't be possible anymore then.
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D153541
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
We're getting asserts for duplicate section registration during
linking which stems back to these sections. From previous
discussions, it seems like these are metadata sections that can
be dropped. See the discussion in D116474 and
https://bugs.llvm.org/show_bug.cgi?id=45111.
Differential Revision: https://reviews.llvm.org/D152574
