OSDev.wiki

C Library: Difference between revisions

Page Discussion

C Library (view source)

Revision as of 13:19, 10 November 2014

278 bytes added ,  9 years ago
Rewrite and improve section on MyOS libc
[unchecked revision][unchecked revision]
VisualWikitext
(added a little MUSL info)
(Rewrite and improve section on MyOS libc)
Line 1:
The C standard library provides string manipulation (string.h), basic I/O (stdio.h), memory allocation (stdlib.h), and other basic functionality to [[C]] programs. The interface is described in the C standard, with further additions described in [[POSIX]] as well as vendor extensions. On Unix platforms, the library is named <tt>libc</tt> and is linked automatically into every executable.
{{stub}}
 
You need a C standard library implementation with the necessary features to run C programs on your operating system. [[C++]] programs can usually use the C standard library as well and the [[C++]] implementation is normally built on top of libc. It is possible to use the C standard interface in a kernel if the library implementation supports this.
The ''C standard library'' provides basic functionality such as string manipulation, basic I/O, and memory allocation.
 
== Freestanding and Hosted ==
There are three situations where you are likely to want to have one:
 
There are two flavors of the C compilation environment: Hosted, where the standard library is available; and freestanding, where only a few headers are usable that contains only defines and types. The hosted environment is meant for user-space programming while freestanding is meant for kernel programming. The hosted environment is hosted, but you can switch to the freestanding by passing <tt>-ffreestanding</tt> to your compiler.
# If you want to have some traditional C functions that you can use inside your kernel (especially printf), then you will need to link a C library into your kernel when you build it.
# Most applications in userspace expect to be able to access traditional C support functions. These functions are usually supplied to userspace in the form of a "runtime C library", that can be dynamically linked into user applications at runtime.
# The C library header files are used extensively during C and C++ compilations.
 
The <tt>__STDC_HOSTED__</tt> macro expands to <tt>1</tt> on hosted implementations, or <tt>0</tt> on freestanding ones. The freestanding headers are: <tt>&lt;float.h&gt;</tt>, <tt>&lt;iso646.h&gt;</tt>, <tt>&lt;limits.h&gt;</tt>, <tt>&lt;stdalign.h&gt;</tt>, <tt>&lt;stdarg.h&gt;</tt>, <tt>&lt;stdbool.h&gt;</tt>, <tt>&lt;stddef.h&gt;</tt>, <tt>&lt;stdint.h&gt;</tt>, and <tt>&lt;stdnoreturn.h&gt;</tt>. You should be familiar with these headers as they contain useful declarations you shouldn't do yourself. GCC also comes with additional freestanding headers for [[CPUID]], [[SSE]] and such.▼
==Versions==
 
== Implementations ==▼
The C standard describes two versions of each C library: the complete "hosted" library and the "freestanding" one. The so-called "freestanding library" consists of a handful of header files, which contain only defines and typedefs and are used only during compilations.
 
There are several open-source C library packages avaialbleavailable, and using one may be a viable solution for you. All of them will require some degree of modification to suit your needs. You may instead wish to roll your own, but keep in mind that a good C library implementation often requires 10 years or more to create.▼
▲The <tt>__STDC_HOSTED__</tt> macro expands to <tt>1</tt> on hosted implementations, or <tt>0</tt> on freestanding ones. The freestanding headers are: <tt>&lt;float.h&gt;</tt>, <tt>&lt;iso646.h&gt;</tt>, <tt>&lt;limits.h&gt;</tt>, <tt>&lt;stdalign.h&gt;</tt>, <tt>&lt;stdarg.h&gt;</tt>, <tt>&lt;stdbool.h&gt;</tt>, <tt>&lt;stddef.h&gt;</tt>, <tt>&lt;stdint.h&gt;</tt>, and <tt>&lt;stdnoreturn.h&gt;</tt>.
 
There is a comparison table of some of these at: [http://www.etalabs.net/compare_libcs.html]▼
GCC defaults to a hosted implementation, but can switch to a freestanding one with the <tt>-ffreestanding</tt> argument.
 
===What's the Point of Freestanding?===
The point of "freestanding" C libraries is this: all Clib packages are supposed to provide one that contains the listed .h files. If you are writing your kernel in
C (or C++), you should care about portability. Including these header files in your kernel and '''using''' the provided macros, defines
and typedefs will dramatically increase the portability of your code, and you probably won't regret it later.
 
==Creating= aMyOS Clibc Library===
{{Main|Creating a C Library}}
 
The best option, in terms of code quality and integration with your operating system, is to write your own C library. You can aim for making a clean and high-quality implementation that follows standards well. It will integrate cleanly with your kernel as no portability layer is needed. You can be secure and robust. You can surpass the limits of what you can do with existing implementations. You can add vendor-extensions that replace bad interfaces and do things better. You can break a lot of code because you followed the standards and applications didn't, then fix the applications as well. It can be better than the competition if you make that your goal.
Creating your own minimal C library is relatively easy, although providing all the primitives needed by real third party software (such as binutils and gcc) is a considerably harder task. You may well wish to save yourself the effort and use one of the below C libraries and adapt it to your needs.
 
This is the idealist path and most in the osdev spirit. It has a lot of advantages, but has the steep price of requiring a lot of effort. This may very well be worth it if your goal is to make a ''good'' operating system, not just ''a'' operating system. You don't have to be a libc expert when starting out, but you'll be one when you're done. You might just realize much of the competition out there isn't very good.
▲==Implementations==
 
Creating your own minimal C library is relatively easy. Providing all the primitives needed by real program is a much larger task, but straightforward as you can attempt to cross-compile the software and implement all the missing features causing compilation errors.
▲There are several open-source C library packages avaialble, and using one may be a viable solution for you. All of them will require some degree of modification to suit your needs. You may instead wish to roll your own, but keep in mind that a good C library implementation often requires 10 years or more to create.
 
=== Newlib ===▼
▲There is a comparison table of some of these at: [http://www.etalabs.net/compare_libcs.html]
 
▲===Newlib===
* The license is unrestricted (not GPL or LGPL), but each file likely has a different copyright notice.
* Requires threading, so is more appropriate for a runtime library
* About 400 functions supported
* 17 required system calls
* [http://sourceware.org/newlib/ newlib website]
 
=== GlibC ===
* Should be absolutely complete▼
* GPL license
▲* Should be absolutely complete (even has all the bloat)
* [http://www.gnu.org/software/libc/ glibc website]
 
===Solar's PDCLibMusl ===
* MIT or BSD licenses on all sourcecode (permissive)▼
* No kernel portability layer, uses the Linux system calls directly.
* aA full set of math and printf functions▼
* Support for about 1200 functions
* Many system calls needs to be implemented as it assumes you are a full Linux
* [http://www.etalabs.net/musl/ musl website]▼
 
=== PDCLib ===
* Creative Commons Zero license (basically public domain)▼
* Under active development, and not at full working release 1.0 yet
▲* Creative Commons Zero license (basically public domain)
* Good for linking into kernels
* Support for about 120 functions, currently
Line 54 ⟶ 52:
* [http://pdclib.e43.eu/ PDCLib website]
 
===microClibC uClibc ===
* LGPL license
* [http://www.uclibc.org/ uclibc website]
 
===Musl diet libc ===
▲* MIT or BSD licenses on all sourcecode (permissive)
* very linuxy (never intended for hobbyOS porting)
▲* a full set of math and printf functions
* support for about 1200 functions (basically gives you a free posix compatibility layer)
* very few comments in the code that did not come from BSD
* about 210 syscalls need to be implemented (and it doesn't tell you which ones out of a list of over 400)
▲* [http://www.etalabs.net/musl/ musl website]
 
===diet libc===
* GPL license
* [http://www.fefe.de/dietlibc/ dietlibc website]
 
===Caprice Google's Bionic ===
* MITBSD license (permissive)
* noNo support for locales▼
* About 100 function calls supported
* noNo libthread_db or libm implementation▼
* No wide chars, only printf supported out of the printf family
* itsIts own smallish implementation of pthreads based on Linux futexes▼
* 11 required system calls
* supportSupport for x86, ARM and ARM thumb CPU instruction sets and kernel interfaces▼
* x86 only -- more than a dozen files written in GAS assembler
* [http://www.libcaprice.com ccaprice website]
 
===Google's Bionic===
* BSD license (permissive)
▲* no support for locales
▲* no libthread_db or libm implementation
▲* its own smallish implementation of pthreads based on Linux futexes
▲* support for x86, ARM and ARM thumb CPU instruction sets and kernel interfaces
 
* [https://github.com/android/platform_bionic/tree/master/libc bionic website]
 
== Standards ==
 
Especially if you want to roll your own C lib, you may want to buy the ISO/IEC 9899 specification to work from.
Line 96 ⟶ 76:
following sites and search for document "ISO/IEC 9899".
 
* Specification Stores:
** [http://webstore.ansi.org From ANSI]
** [http://infostore.saiglobal.com/store From SAI Global]
** [http://www.iso.org/iso/home/store From ISO Store]
Anonymous user
Retrieved from "https://osdev.wiki/wiki/Special:MobileDiff/2950"