f626a35086
When supporting "overlay" vs "fullbuild" modes, "what ABI are you using?" becomes a fundamental question to have concrete answers for. Overlay mode MUST match the ABI of the system being overlayed onto; fullbuild more flexible (the only system ABI relevant is the OS kernel). When implementing llvm-libc we generally prefer the include-what-you use style of avoiding transitive dependencies (since that makes refactoring headers more painful, and slows down build times). So what header do you include for any given type or function declaration? For any given userspace program, the answer is straightforward. But for llvm-libc which is trying to support multiple ABIs (at least one per configuration), the answer is perhaps less clear. This proposal seeks to add one layer of indirection relative to what's being done today. It then converts users of sigset_t and struct epoll_event and the epoll implemenations over to this convention as an example.
16 lines
682 B
ReStructuredText
16 lines
682 B
ReStructuredText
===========
|
|
Usage Modes
|
|
===========
|
|
|
|
The libc can used in two different modes:
|
|
|
|
#. The **overlay** mode: In this mode, the link order semantics are exploited
|
|
to overlay implementations from LLVM's libc over the system libc. See
|
|
:ref:`overlay_mode` for more information about this mode. In this mode, libc
|
|
uses the ABI of the system it's being overlayed onto. Headers are NOT
|
|
generated. libllvmlibc.a is the only build artifact.
|
|
#. The **fullbuild** mode: In this mode, LLVM's libc is used as the only libc
|
|
for the binary. See :ref:`fullbuild_mode` for information about this mode.
|
|
In this mode, libc uses its own ABI. Headers are generated along with a
|
|
libc.a.
|