24 lines
1.2 KiB
ReStructuredText
24 lines
1.2 KiB
ReStructuredText
==========================
|
|
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.
|