DWARF module versioning
=======================
-1. Introduction
-===============
+Introduction
+============
When CONFIG_MODVERSIONS is enabled, symbol versions for modules
are typically calculated from preprocessed source code using the
from the DWARF debugging information, which contains the necessary
details about the final module ABI.
-1.1. Usage
-==========
+Usage
+-----
gendwarfksyms accepts a list of object files on the command line, and a
list of symbol names (one per line) in standard input::
-h, --help Print this message
-2. Type information availability
-================================
+Type information availability
+=============================
While symbols are typically exported in the same translation unit (TU)
where they're defined, it's also perfectly fine for a TU to export
elsewhere. The name of the symbol pointer is expected to start with
`__gendwarfksyms_ptr_`, followed by the name of the exported symbol.
-3. Symtypes output format
-=========================
+Symtypes output format
+======================
Similarly to genksyms, gendwarfksyms supports writing a symtypes
file for each processed object that contain types for exported
DWARF format produced by **--dump-dies**, but with type references
instead of fully expanded strings.
-4. Maintaining a stable kABI
-============================
+Maintaining a stable kABI
+=========================
Distribution maintainers often need the ability to make ABI compatible
changes to kernel data structures due to LTS updates or backports. Using
transform the inputs for symbol versioning, the user is responsible for
ensuring that their changes actually won't break the ABI.
-4.1. kABI rules
-===============
+kABI rules
+----------
kABI rules allow distributions to fine-tune certain parts
of gendwarfksyms output and thus control how symbol
the format is extensible enough to allow further rules to be added as
need arises.
-4.1.1. Managing definition visibility
-=====================================
+Managing definition visibility
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A declaration can change into a full definition when additional includes
are pulled into the translation unit. This changes the versions of any
KABI_DECLONLY(s);
-4.1.2. Adding enumerators
-=========================
+Adding enumerators
+~~~~~~~~~~~~~~~~~~
For enums, all enumerators and their values are included in calculating
symbol versions, which becomes a problem if we later need to add more
KABI_ENUMERATOR_IGNORE(e, C);
KABI_ENUMERATOR_VALUE(e, LAST, 2);
-4.3. Adding structure members
-=============================
+Adding structure members
+------------------------
Perhaps the most common ABI compatible change is adding a member to a
kernel data structure. When changes to a structure are anticipated,
reserved space in data structures and hiding members that don't change
the ABI when calculating symbol versions.
-4.3.1. Reserving space and replacing members
-============================================
+Reserving space and replacing members
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Space is typically reserved for later use by appending integer types, or
arrays, to the end of the data structure, but any type can be used. Each
simplify the process and also ensure the replacement member is correctly
aligned and its size won't exceed the reserved space.
-4.3.2. Hiding members
-=====================
+Hiding members
+~~~~~~~~~~~~~~
Predicting which structures will require changes during the support
timeframe isn't always possible, in which case one might have to resort