| Issue |
175715
|
| Summary |
Formalise JIT address / pointer / flags relationships.
|
| Labels |
orcjit
|
| Assignees |
lhames
|
| Reporter |
lhames
|
### Description
ORC supports cross process JIT compilation / linking. We call the process that defines and links the JIT'd program the _controller_, and the process that executes the JIT'd code the _executor_. To support this cross-process model ORC needs (at minimum) a target independent address type for JIT linker arithmetic.
ORC currently defines the following relevant types:
`ExecutorAddr`: a class wrapper around uint64_t, intended to represent addresses in the executing process. (see also `ExecutorAddrRange` and `ExecutorAddrDiff`).
`ExecutorSymbolDef`: a class wrapper around a pair of an ExecutorAddr and a JITSymbolFlags. This represents a linkable location that will also be associated with some symbol name. (E.g. SymbolMap is defined as `DenseMap<SymbolStringPtr, ExecutorSymbolDef>`)
These types are replicated in the ORC runtime for use in out-of-process JIT setups.
There are some deficiencies in this design:
1. `ExecutorAddr` has `toPtr` / `fromPtr` operations but doesn't capture potentially relevant non-address aspects of pointers, e.g. tag bits, ARM thumb bit, pointer authentication bits, etc.
2. `ExectorSymbolDef` uses JITSymbolFlags, but JITSymbolFlags mixes linker flags and pointer flags in an ad-hoc way.
3. COMDATs are not supported at all.
In this issue I'd like to work towards a coherent, ergonomic design that addresses these deficiencies.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
