SE-0537: Section Placement Control for Functions

Summary of changes

This proposal extends the @section attribute introduced in SE-0492 to also allow functions to be annotated with @section. This can be useful in embedded systems where some code (for example the boot code for firmware) needs to be in a particular section in the binary.

Motivation

The @section attribute specifies where a particular entity will be placed in an object file. Particularly in embedded environments, linkers and other tools expect certain kinds of symbols to be in specific sections. SE-0492 introduced support for @section for global and static variables, but left functions to a future direction. However, functions also require this support. A prominent use case is firmware entry points and booting schemes, which often require startup code to be in a predefined section:

// code for the function is placed into the custom section
@section("__TEXT,boot")
func firmwareBootEntrypoint() { ... }

This motivation was also outlined in the Future Directions of SE-0492.

Proposed solution

Enable the @section attribute on all kinds of functions, including normal functions (func), initializers (init), deinitializers (deinit), closures, and accessors (get, set, etc.).

Detailed design

The @section attribute can be applied to any kind of function. Some examples to show the syntax at various places:

@section("__TEXT,boot")
func firmwareBootEntrypoint() { ... }

struct MyBootConfig: ~Copyable {
  @section("__TEXT,boot") init() { 
    registerCallback { @section("__TEXT,boot") in 
      ...
    }
  }

  @section("__TEXT,boot") deinit { }

  var bootPhase: Int {
    @section("__TEXT,boot") get { ... }
    @section("__TEXT,boot") set { ... } 
  }
}

Unlike with @section on variables, there are no limitations on the use of @section for generic functions or functions within a generic context, because all functions go into a text section. This also means that @section can be applied to instance functions of types.

The @section attribute applies to the function and any related functions that the implementation produces for it. For example, when applied to an async function, each of the partial functions the implementation generates will respect the @section attribute. Similarly, when a @section attribute is applied to a generic function, it will also apply to any specialization of that generic function that is produced by the compiler, as well as the original generic definition. Finally, if the main function of a @main type has a @section attribute, the same section is used for the actual main entrypoints emitted by the compiler.

Inferring @section on accessors, closures, and local functions

When @section isn't explicitly specified of an accessor or a closure, it can be inferred:

• For a closure or local function, @section will be inferred from its enclosing function (if there is one).

```swift @section("TEXT,boot") func firmwareBootEntrypoint() { func helper() { // infers @section("TEXT,boot")

}

registerCallback { // infers @section("__TEXT,boot") ... } } ```

• An accessor that provides read-only access (get, borrow, yielding borrow, etc.) that is synthesized by the implementation will infer @section from one of these accessors that was written explicitly.

• An accessor that provides read-write or write access (set, mutate, yielding mutate, init, didSet, willSet) that is synthesized by the implementation will infer @section from one of these accessors that was written explicitly. For example:

```swift var scratchSpace: MutableSpan<UInt> { @section("TEXT,boot") borrow { ... } // synthesized "get" will infer @section("TEXT,boot") from 'borrow'

@section("TEXT,boot") mutate { ... } // synthesized "set" will infer @section("TEXT,boot") from 'mutate' } ```

Note that there is no inference of @section from a variable to its accessors, because code and data tend to be in different sections. Local types (and members thereof) also do not have sections inferred.

Lifting restriction on didSet/willSet

SE-0492 placed this restriction on variables with @section:

• the variable must not have property observers (didSet, willSet)

This restriction is unnecessary, and is lifted by this proposal. The didSet or willSet can have a @section attribute on them, which will then be used for inference on the actual accessor (e.g., set) that the implementation synthesizes a symbol for.

Source compatibility

This is a pure extension with no source compatibility impact.

ABI compatibility

The @section attribute deliberately places an entity into a specific section.

Implications on adoption

This feature can be freely adopted and un-adopted in source code with no deployment constraints and without affecting source compatibility. ABI is covered above.

Future Directions

Separate "data" and "function" section attributes

Some declarations in Swift involve emitting both data and function symbols. For example, when defining a type, there can be both a metadata symbol (data) and also a metadata accessor function (a function). Neither this proposal nor SE-0492 allows a @section attribute on a type definition, but if it did, we would need a way to express different sections for data vs. functions. For example, it could look like this:

@section(data, "__DATA,mysection")
@section(function, "__FUNCTION,mysection")
public struct MyStruct { ... }

A @section that specifies neither data nor function would only apply in the places where the determination is unambiguous, as covered by this proposal and SE-0492. New places that emit both data and function symbols, such as type definitions, extensions, or protocol conformances, could then make use of this new syntax.