File: layering.rst

package info (click to toggle)
llvm-toolchain-15 1%3A15.0.6-4
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 1,554,644 kB
  • sloc: cpp: 5,922,452; ansic: 1,012,136; asm: 674,362; python: 191,568; objc: 73,855; f90: 42,327; lisp: 31,913; pascal: 11,973; javascript: 10,144; sh: 9,421; perl: 7,447; ml: 5,527; awk: 3,523; makefile: 2,520; xml: 885; cs: 573; fortran: 567
file content (23 lines) | stat: -rw-r--r-- 1,209 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
==========================
Layering Over Another libc
==========================

When meaningful and practically possible on a platform, llvm-libc will be
developed in a fashion that it will be possible to layer it over the system
libc. This does not mean that one can mix llvm-libc with the system-libc. Also,
it does not mean that layering is the only way to use llvm-libc. What it
means is that, llvm-libc can optionally be packaged in a way that it can
delegate parts of the functionality to the system-libc. The delegation happens
internal to llvm-libc and is invisible to the users. From the user's point of
view, they only call into llvm-libc.

There are a few problems one needs to be mindful of when implementing such a
delegation scheme in llvm-libc. Examples of such problems are:

1. One cannot mix data structures from llvm-libc with those from the
system-libc. A translation from one set of data structures to the other should
happen internal to llvm-libc.
2. The delegation mechanism has to be implemented over a related set of
functions. For example, one cannot delegate just the `fopen` function to the
system-libc. One will have to delegate all `FILE` related functions to the
system-libc.