Prologue support


Prologue support

Patch by Ben Gamari!

This redefines the prefix attribute introduced previously and
introduces a prologue attribute. There are a two primary usecases
that these attributes aim to serve,

  1. Function prologue sigils
  2. Function hot-patching: Enable the user to insert nop operations at the beginning of the function which can later be safely replaced with a call to some instrumentation facility
  3. Runtime metadata: Allow a compiler to insert data for use by the runtime during execution. GHC is one example of a compiler that needs this functionality for its tables-next-to-code functionality.

Previously prefix served cases (1) and (2) quite well by allowing the user
to introduce arbitrary data at the entrypoint but before the function
body. Case (3), however, was poorly handled by this approach as it
required that prefix data was valid executable code.

Here we redefine the notion of prefix data to instead be data which
occurs immediately before the function entrypoint (i.e. the symbol
address). Since prefix data now occurs before the function entrypoint,
there is no need for the data to be valid code.

The previous notion of prefix data now goes under the name "prologue
data" to emphasize its duality with the function epilogue.

The intention here is to handle cases (1) and (2) with prologue data and
case (3) with prefix data.


This idea arose out of discussions[1] with Reid Kleckner in response to a
proposal to introduce the notion of symbol offsets to enable handling of
case (3).

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073235.html

Test Plan: testsuite

Differential Revision: http://reviews.llvm.org/D6454


pccDec 2 2014, 6:08 PM
Differential Revision
D6454: Prologue support
rL223188: ExceptionDemo: Let setMCJITMemoryManager() take unique_ptr, since r223183.

Event Timeline